Citer : Posté le 03/01/2021 22:47 | #

---

Alors là, tu me prends de court !

Je suis chaud pour essayer d'intégrer ça, notamment pour faire rentrer l'alternance gint/OS (qui a des effets de bord sur le matériel) dans ce paradigme. Il y a beaucoup de code dans ta PR donc ça va prendre un moment à disséquer, mais on doit pouvoir s'en sortir.

Je n'ai même pas encore tout lu, mais globalement la façon dont je vois les choses ce serait comme ça :

1. Tenter d'amincir le code en sortant ce qui est relativement indépendant (setjmp et compagnie)
2. Intégrer par morceaux les définitions de ton système de contextes, pour implémenter l'alternance gint/OS avec
3. Si possible, intégrer le scheduler en premier et ensuite l'API de threading

Idéalement il faudrait que tu puisses tester en même temps que moi au fur et à mesure, il y aura sans doute des ajustements à faire de temps en temps.

Quelque chose qui me gêne c'est que tu modifies le flot principal de toutes les interruptions pour lancer le scheduler. Pourquoi ? Les interruptions sont traitées par le noyau, ça ne pose normalement pas de problème de laisser le gestionnaire d'interruptions se lancer et appeler le scheduler seulement lorsque son timer expire.

---

Citer : Posté le 04/01/2021 17:30 | #

---

Du coup j'y ai réfléchi. Le passage de gint à l'OS, dans "l'usage normal de gint", est juste un context switch sur les modules périphériques : en particulier l'exécution est continue (on saute nulle part) et il n'y a rien à ordonnancer (tout est dirigé par l'utilisateur). J'ai tenté de formuler tout ça dans un système de threads mais je suis arrivé à plusieurs problèmes, principalement dus au fait qu'on s'attend à pouvoir retourner dans l'OS peu importe dans quel thread de gint on est, ce qui viole l'idée que le thread OS a un PC unique (mon idée était de partager le contexte CPU du thread OS avec le thread gint principal, mais du coup ça empêche aux autres threads gint de revenir à l'OS).

Évidemment l'idée d'exécution parallèle avec deux contextes CPU différents a beaucoup plus de sens dans le cas de ton debugger. Il va donc falloir bien réfléchir. Je vois plusieurs choses à traiter attentivement :

• D'abord le fait que l'usage classique de gint_switch() ne contient pas d'idée d'exécution parallèle.
• Ensuite le fait que l'influence de gint est normalement inexistante quand on est dans l'OS (je suppose que tu as hacké pour garder le timer allumé).
• Et enfin le fait que passer automatiquement (par l'ordonnanceur) du thread CASIOWIN à un thread gint (ou l'inverse) est toujours ou presque toujours malvenu.

J'ai tenté de séparer comme ci-dessous, ce qui ne marche pas et que je cite juste pour noter ce que j'ai essayé :

Threads CASIOWIN
└─ Thread CASIOWIN unique
Threads gint
├─ Thread gint principal
└─ Autres threads gint...

Dans l'immédiat le plus économe conceptuellement me semble d'être de séparer le concept de contexte matériel (modules périphériques) utilisé pour l'alternance gint/OS et le concept de contexte et logiciel utilisé pour le threading, avec un tout petit extra dans le threading pour lier, si on le souhaite, un certain contexte matériel à un certain thread.

Dans ce modèle, l'usage normal de gint ressemble à ça :

[Thread 0] Le thread principal de gint (contexte matériel : variable)

Et ton usage pour le traceur ressemble à ça :

[Thread 0] Le thread principal de gint (contexte matériel : gint uniquement)
[Thread 1] Le thread à tracer (contexte matériel : celui de l'OS uniquement)

Ici l'élément important c'est que le thread OS a le contexte matériel de l'OS donc dès qu'il est sélectionné par l'ordonnanceur ou lancé par ton traceur on passe au contexte matériel de l'OS. (Tu pourrais laisser le contexte matériel variable sur le thread gint, mais comme il ne peut y avoir qu'un seul contexte matériel OS l'utiliser dans le thread principal influencerait le programme en cours de debug. Je crois que tu fais ça par endroits mais je suis plus sûr.)

De l'idée que j'en ai là tout de suite, le changement de contexte matériel et logiciel pourrait s'implémenter sans trop modifier le coeur de gint, et presque laisser la majorité de l'API de threading et l'ordonnanceur à une lib externe (modulo ce qui suit dans mon message). Je serais tenté de partir dans cette direction si c'est réalisable, parce que ça coûtera moins de travail pour l'intégrer, que ce sera plus facile de porter pour SH3, et parce que moins modifier le coeur de gint veut aussi dire moins de risque d'introduire des bugs architecturaux pétés. ^^"


C'est le cas de toute interruption, de toute façon tout fonction qui utilise r8...r15 les restaure, et dans le gestionnaire d'interruptions je n'active les interruptions à aucun point où ils ne sont pas à leur valeur d'origine. En tous cas ce que tu dis là est vrai, mais ne nécessite pas de prendre toutes les interruptions en otage.


Sur SH4, tu peux interrompre un callback de timer avec l'interruption de l'ordonnanceur préemptif, il suffit que cette interruption soit d'un niveau plus haut. Si on la colle à 15 rien ne pourra lui échapper.


Je sais pas pourquoi tu parles de TRAPA ici (le gestionnaire d'exceptions à VBR+0x100 n'est pas du tout impliqué). Par contre tu as raison sur le fait que le gestionnaire du timer active les interruptions, ce qui est inacceptable pour l'ordonnanceur. C'est le seul problème que je vois actuellement. Ça ne me pose pas du tout de problème d'ajouter une extension à l'API timer pour créer un timer de priorité 15 dont le callback est appelé sans réactiver les interruptions ; en tous cas je préfère largement ça à interrompre le flot de toutes les interruptions. Est-ce que ça te paraît faisable ?


Ah d'accord parce que tu voyais le changement de contexte comme un appel système, c'est bien ça ? D'où le TRAPA. Il n'y a pas du tout de syscalls dans gint pour l'instant, faudrait que je réfléchisse pour voir si ça vaut la peine d'en ajouter. À vue de nez ce n'est pas nécessaire, puisque tout tourne déjà en ring 0 il suffit que l'ordonnanceur masque les interruptions si on l'appelle manuellement et ça fait le même travail.

L'autre truc qui me paraît louche et qui rend compliqué le fait de "simplement" implémenter le changement de contexte matériel/logiciel dans gint pour garder l'API de threading [et peut-être l'ordonnanceur] dans une lib c'est cette fonctionnalité de remonter à la création du thread quand tu le détruis. J'ai lu une partie des commentaires mais je n'en comprends pas l'usage. Tu peux m'expliquer ça ?

---

Citer : Posté le 06/01/2021 09:28 | # | Fichier joint

---

Ce message qui a commencé comme une simple discussion de ce qui est intéressant ou pas dans les idées qu'on a évoquées jusqu'à présent a tourné en modèle complet. Comme je savais que le message allait être long j'ai fait plusieurs tours de toutes les idées et je pense que le modèle que je présente ci-dessous est déjà un peu mature. La lecture longue ne devrait donc, je l'espère, pas être gâchée.


Eh bien, hmm... ça se pourrait mais je voudrais prendre les choses dans l'ordre, et notamment séparer les trucs intéressants ou pas dans ce qu'on a dit jusqu'ici.

Pour situer tout ce qui suit dans ce message, mon but est d'équilibrer trois objectifs :
(F) les fonctionnalités et la flexibilité du système. Je veux implémenter ce dont tu as besoin pour ton traceur.
(P) la performance des applications et en particulier des add-ins « classiques ».
(S) la simplicité de fusionner ton travail dans gint, et de maintenir le résultat.

(Le but donc c'est de maximiser FPS, et je te promets que c'était pas fait exprès. )

Voilà quelques points qui me paraissent importants par rapport à ces trois choses :

Fonctionnalités
• Comme on n'a qu'un seul cœur, les seuls intérêt des threads pour les applications gint classiques sont de (I1) alterner deux flots d'exécution indépendants (c'est-à-dire écrire des coroutines), et (I2) effectuer des calculs sensiblement parallèles sans avoir à ordonnancer à la main. (I1) est intéressant en tant que coroutines, et encore plus intéressant si les deux flots sont l'OS et un debugger (ça donne ton traceur). (I2) c'est moyen, je vois pas vraiment de raison de préférer un ordonnanceur automatique type round robin quand planifier à la main ira toujours plus vite ; mais je veux bien coder ce qu'il faut pour le rendre possible.
• Je préfère ne pas modifier trop le noyau : implémenter seulement les context switch et les world switch et laisser la lib threads extérieure ; pas pour des raisons idéologiques, mais pour des raisons pragmatiques de réussir à faire la fusion sans y passer des mois.
• Je préfère éviter les tricks comme hijack les interruptions ou de sauter à la fin des threads.
• Je veux que ce soit compatible en API avec gint 2.1.

Performance
• Toujours parce qu'on n'a qu'un cœur, plein de choses qu'on pourrait naïvement faire avec des threads seront plus lentes que faites proprement à la main (en inlinant en quelque sorte l'ordonnanceur dans la logique du programme, ce qu'on fait déjà tout le temps). Je ne cherche donc pas à supporter les constructions multi-threadées qui sont plus lentes que leurs équivalents mono-threadés quand il y en a.
• J'aimerais minimiser l'impact sur les programmes qui ne sont pas multi-threadés (donc ralentir les interruptions, même si on peut le faire, c'est pas idéal).

Simplicité
Pas grand-chose à dire ici, l'idée générale me plaît mais avoir une implémentation stable, testée et qui répond à ton besoin me plaît davantage.

Ce qu'on veut faire avec

Donc voilà dans tes trois messages ce que tu as (pour l'instant) raconté qu'on pourrait faire avec, comme ça je passe ça au crible et j'en tire ma vision de ce qu'on devrait pouvoir supporter.


Le principe du traceur c'est en gros (I1) où l'on fait un context switch et un world switch en même temps sur la base d'une interruption UBC (on ne peut pas attraper les autres sinon soit on casse l'OS soit on fait une redirection à la Kristaba que tu appelles Hyperviseur type-1, ce qui m'intéresse pas immensément par rapport à l'autre version avec l'UBC).


Toutes ces choses (envoi sur le port 3-pin, échanges par USB, UBC) sont contrôlées par des interruptions, et ne nécessitent pas d'avoir du threading plus élaboré que le context switch normal des interruptions (je les planifiais déjà avant que cette idée ne soit mise sur la table). En plus, la musique et les échanges par USB sont assez sensibles au timing donc il n'y a pas vraiment de raison de les ordonnancer à un autre moment que quand le matériel signale qu'une action est nécessaire.


Pour un unikernel la notion d'ordonnanceur préemptif est assez limitée, mais je trouve ça normal de pouvoir la supporter. Notons que tu peux pas préempter n'importe quoi non plus, et ce n'est pas un problème à mon goût (on n'est pas du tout en train de faire un RTOS).


Je profite de la mention du terme pour dire que gint ne peut pas implémenter de processus parce que la mémoire n'est pas abstraite (pas de MMU) et je n'ai pas l'intention de partir dans cette direction ; donc on reste bien sur des flots d'exécution qui partagent toutes les ressources, donc des threads.


C'est intéressant, mais je ne pense pas que ce soit utile. Ces procédures ne sont pas parallèles : les drivers clavier et USB sont sensibles au timing et s'exécutent toujours et uniquement lorsqu'une interruption le demande ; pareil pour le thread 7 ; les threads 4 à 6 et 8 sont invoqués à des instants différents du cycle de jeu et on n'a surtout pas envie de laisser un ordonnanceur préemptif les contrôler. (Tu imagines si tu fais 14 ticks de déplacement de mobs sans simuler la physique ?)

Imaginons que tu codes un jeu avec ce modèle-là. À mon sens, si tu passes d'un thread à l'autre manuellement tu vas juste reproduire la logique qu'on utilise actuellement dans un jeu avec plus de code et des changements de contexte, violant (P) ; et si tu utilises un ordonnanceur préemptif pour changer automatiquement de thread tu fragilises énormément le design, risquant des problèmes de timing sur les drivers et la génération du son, des problèmes de désynchronisation entre les différentes parties du jeu, tout en continuant de subir les pertes de performance liées au changement de contexte.

La plupart des applications seront comme ça je pense, et sauront comment ordonnancer leurs composants bien mieux qu'une méthode automatique. C'est ce qui me fait dire que l'intérêt de (I2) est vraiment limité (et dans mon plan l'ordonnanceur est externe, gint ne fournit que les context et world switch). Donc même si c'est stylé, je vois pas de cas d'usage raisonnable, donc ça me paraît pas intéressant à supporter. (Tu peux le faire dans une lib mais gint devrait pas hiérarchiser les threads par exemple.)


Le notion d'hyperviseur nécessite d'avoir un niveau d'abstraction/privilège plus bas que les noyaux que tu lances. Sur la calculatrice où tout est en ring 0, c'est un peu difficile à définir exactement. Mais en gros ce que tu décris là reprend le designe du debugger de Kristaba mais interromp gint en plus de l'OS (bon courage pour coopérer avec la VBR de l'OS).

Si tu veux faire un vrai hyperviseur bien séparé de l'add-in, où l'hyperviseur charge gint dans la mémoire et fait les world switch, alors c'est indépendant de gint. Ce dont tu as besoin, ce n'est pas d'ajouter des threads à gint, mais de le modifier pour en sortir les world switch et ajouter un peu de flexibilité sur le démarrage (le rendre compatible avec ton hyperviseur en sommet). Je vois pas trop d'interêt, puisqu'on peut faire plus direct et élégant.

En réalité tu peux simplement faire charger ton hyperviseur en même temps que l'add-in et modifier le world switch de gint pour garder le contrôle de la VBR. Ce qui revient exactement au gint multi-threadé que je propose plus bas mais tu as un hook sur toutes les interruptions de gint et de l'OS.


De ce que je comprends c'est pareil que l'autre mais l'hyperviseur est dans le handler DBR au lieu d'être dans le point d'entrée de la VBR. Et donc tu peux y entrer automatiquement dans un grand nombre de situations grâce à l'UBC. Ça tu peux vraiment facilement le faire avec le gint multi-threadé que je propose plus bas, conserver le contrôle de DBR est beaucoup plus facile que conserver le contrôler de la VBR. Comme tu l'as remarqué, c'est vraiment la même chose que gint tout seul avec un add-in bien écrit, on place juste les frontières entre les composants à des endroits différents.

Personnellement, je vois pas de raison de déployer des outils aussi compliqués qu'un hyperviseur sous gint et sous l'OS. Au contraire, je pense qu'analyser correctement la situation et mettre en place la solution correcte la plus efficace est une preuve de pertinence. L'étude préliminaire clarifie le design donc on est mieux guidés quand on code, l'architecture est plus simple donc ça va plus vite et avec moins de bugs, et à la fin le projet marche plus rapidement et donne le même résultat.


Pour (1) et (3), l'hyperviseur VBR requiert de détourner les interruptions de l'OS à la façon de Kristaba. Si tu fais ça, tu peux simplement mettre ton handler dans gint et coder les statistiques dans gint. (2), tu peux déjà le faire avec ton traceur ? Quant à (4) on peut le faire dans mon modèle aussi, c'est bien obligé puisque je veux supporter ton traceur et c'en est le principe même.


Là aussi je ne vois pas le besoin d'avoir un hyperviseur (quelque chose en-dessous du noyau), tu donnes simplement à l'UBC des privilèges symboliques plus élevés, ce que tu peux faire même si ton code est techniquement au-dessus de noyau (typiquement dans une bibliothèque). D'ailleurs gintctl fait déjà des fourberies de ce genre dans le navigateur de mémoire en sautant les instructions qui accèdent aux adresses provoquant des TLB error. (Dans ce cas l'accès est détectée par une exception à VBR+0x400 avec un TLB miss mais c'est exactement pareil si c'était DBR avec un user break.)

Tout ça reste très pété et très loin, donc si tu veux bien je te propose de discuter d'abord d'un modèle portant sur les applications simples et une fois qu'il sera clair de voir s'il marche pour ces applications pétées. Parce que je ne suis pas sûr qu'on le code un jour, et si on le code qu'on le code comme on l'imagine aujourd'hui, donc je préfère y aller doucement.

Pour résumer, voilà mon cahier des charges :
• Avoir une notion de thread OS qui provoque un world switch quand on y passe (pour le traceur).
• Permettre l'implémentation d'un ordonnanceur préemptif (de préférence en externe pour customiser la politique temporelle).
• Éventuellement supporter un world switch qui préserve soit la VBR soit l'UBC pour implémenter une de tes idées d'hyperviseur (de préférence l'UBC).

Voilà ce qui ne me semble pas être des objectifs intéressant :
• Mettre dans des threads du code qui est déjà très bien contrôlé par des interruptions.
• Traiter les threads comme des processus (en particulier pas besoin de hiérarchie).

Séparation kernel/add-in et « threader le kernel » ; vers un kernel atomique par construction

Prenons un peu de recul, parce que cette partie est très importante. gint est un unikernel, donc le noyau se mêle forcément au code de l'utilisateur, en particulier en exposant ses fonctionnalités dans une bibliothèque. Contrairement à Linux où tout passage dans le noyau est contrôlé par un syscall (qui induit un changement de contexte), ici les entrées et sorties de gint sont floues et non contrôlées. C'est fait exprès et ça doit rester comme ça.

Dans un unikernel, la limite entre le noyau et l'application est floue et c'est fait exprès.

La vérité c'est que la limite est partiellement artificielle. Sous Linux, on met dans le noyau les fonctions qui ne doivent pas être accessibles aux applications pour des raisons de sécurité. Mais en fait des choses comme lire l'heure peuvent parfaitement être faites par l'application, et c'est un tel avantage de performance que le vdso(7) a été inventé pour mettre des fonctionnalités originellement noyau dans le userspace.

La situation avec gint c'est une version extrême de ça couplée au fait qu'on se moque de la sécurité puisque la relation entre l'add-in et le noyau est coopérative (et de toute façon on ne peut rien sécuriser puisque l'add-in fait ce qu'il veut, il tourne en ring 0). rtc_get_time() est une fonction qui s'exécute sans sauvegarder de contexte et a toutes les raisons de le rester. Et ce serait paradoxal de payer un coût en performance pour faire un context switch si deux threads veulent lire l'heure en même temps, alors que ça marche déjà tout seul (y'en a juste un qui va s'apercevoir après s'être fait interrompre pendant 100 ms que le CF est passé à 1 et va recommencer sa lecture).

Dans un gint multi-threadé, tous les threads auront fondamentalement accès à gint en parallèle puisque le noyau est couplé avec le code.

Reste le fait qu'il y a bel et bien des fonctions qu'on ne peut pas interrompre — principalement certains drivers, le gestionnaire de threads et les gestionnaires d'interruptions. Et c'est là que je sors la carte piège : puisque la notion de noyau vs userland est volontairement floue dans ce design d'unikernel, on peut définir le noyau de gint comme l'ensemble de ces fonctions dont on doit contrôler l'accès.

À première vue ça ne fait que jouer sur les mots, mais en réalité c'est très important : comme ces parties sont ininterruptibles, on ne peut pas changer de thread pendant qu'elles s'exécutent. Formulé autrement avec la nouvelle définition, tous les opérations noyau sont atomatiques. Ça veut dire que si un thread rentre dans le noyau, on continue de l'exécuter jusqu'à ce qu'il en sorte. Et donc à tout instant l'exécution est dans une de deux situations :

• Soit tous les threads sont hors du noyau, et dans ce cas-là le thread courant peut tout à fait entrer dedans.
• Soit un thread est dedans et dans ce cas c'est le thread courant puisqu'une fois entré dans le noyau il ne peut plus être interrompu, et tous les autres threads sont dehors.

Définir le noyau comme l'ensemble des fonctions ininterruptibles révèle que même si on le partage dans tous les threads son exécution n'est jamais parallèle et toujours bien définie.

Et donc en particulier...


Non seulement on peut, mais en plus on n'en a pas besoin. En effet, toute opération noyau qui est démarrée continue sans interruption jusqu'à ce qu'elle se termine. Même si le noyau utilise la pile du thread qui l'a appelé, il n'y a de risque que des données se perdent. Une seule question se pose, c'est si tu changes de thread pendant que tu es dans le noyau. Mais je vois plein de solutions ici (je peux détailler plus tard, c'est du détail d'implémentation) donc pour moi il n'y a pas besoin de pile noyau. L'intérêt ? Tu peux appeler pthread_exit() sans avoir à changer de pile (donc pas de trapa, tout est simple et performant et écrit en C).

Tout cela devrait expliquer le titre de cette partie. Non seulement le kernel n'a pas à être un thread (ce serait contraire aux principes de l'unikernel) mais en plus il n'a pas besoin de l'être, parce que si on regarde les choses sous le bon angle on réalise qu'on peut le partager entre tous les threads sans que ça crée de conflit. Pour cette exacte même raison, il n'y a pas besoin de trapa pour passer dans le kernel, il suffit d'appeler les fonctions directement.

Bien sûr, il faut quand même bien identifier les fonctions ininterruptibles dont je parle, ce qui concerne je pense :
• Certaines parties des drivers très sensibles au timing : port série, USB. Ceux-là pourront appeler un atomic_begin() et atomic_end() quand ils en ont besoin.
• Le gestionnaire de threads ; ce serait stupide qu'il se fasse interrompre.
• Les gestionnaires d'interruptions, qui sont déjà ininterruptibles parce qu'ils s'exécutent avec SR.BL=1.

Je ferais quand même la distinction entre les drivers ininterruptibles et ceux qui sont simplement MT-Unsafe. Si un driver ne peut pas être interrompu sans casser son interaction avec le matériel (genre USB), alors il est ininterruptible et doit être protégé. Si on peut l'interrompre mais qu'il faut juste ne pas y toucher jusqu'à ce qu'il reprenne, il est MT-Unsafe. Par exemple tu peux interrompre le driver TMU pendant qu'il initialise un timer et reprendre l'initialisation plus tard. Les drivers qui ne sont que MT-Unsafe n'ont pas à être protégés par le noyau, c'est à l'utilisateur de se démerder pour ne pas les appeler dans deux threads en même temps (car protéger automatiquement violerait (P) en induisant un surcoût pour les applications mono-threadées et les applications qui savent ce qu'elles font).

Enfin, pour finir cette partie note qu'actuellement tu peux interrompre n'importe quel driver de gint avec une interruption, et à bien y réfléchir je pense que ça peut créer des bugs. Je n'avais pas trop pensé à ça jusqu'à ce que tu mettes le sujet sur la table, donc merci. xD

Le modèle que je propose

Voilà donc le modèle que je propose de mettre en place, et qui répond d'après mon analyse aux besoins cités dans le cahier des charges (et qui permet même les fonctionnalités pétées type hyperviseur, mais on en reparlera plus tard).

Le noyau est structurellement atomique et partagé entre tous les threads. Si on reprend la définition que j'ai donnée tout à l'heure du noyau comme l'ensemble des fonctions atomiques, alors il est clair qu'on peut partager le noyau avec tous les threads. Ça évite d'avoir un « thread noyau », ce qui n'est pas dans la philosophie de l'unikernel. Ainsi, chaque thread dont le world est gint a accès à gint, et gint utilise soit des atomic_begin() et des atomic_end() soit SR.BL=1 pour s'assurer de son propre bon fonctionnement.

Context switch et world switch comme des fonctions de l'API. Les deux sont ininterruptibles, et programmés en assembleur (en tout cas le début et la fin sont programmés en assembleur ; le context switch est obligé parce qu'il modifie plein de registres, le world switch est initié par cpu_setvbr() qui est aussi en assembleur).

Threads OS avec un world switch. On ajoute une notion de thread OS qui fait un world switch en même temps que le context switch.

World switch customisé. Si tu veux conserver le contrôle de la VBR durant un world switch (pour l'hyperviseur type-1), tu peux appeler ou faire appeler gint_setvbr() avec ton adresse de VBR. Si tu veux conserver le contrôle de DBR (pour un hyperviseur type-2), tu peux désactiver le changement de contexte dans le driver UBC.

Notons que l'alternance gint/OS classique n'est du coup pas vraiment un changement de thread, ça consiste plus à déplacer le thread d'un world à l'autre tout en continuant de l'exécuter (ça me satisfait en termes de « faire rentrer dans le paradigme »).

Voilà le diagramme.


Tricks a priori pas nécessaires


Quand on y réfléchit, la difficulté là-dedans c'est que l'état que tu veux sauvegarder avant de changer de thread n'est pas l'état du processeur au moment où l'ordonnanceur est appelé (... par l'interruption), mais l'état du processeur où moment où le code utilisateur se fait interrompre. Un état qui existe plus tôt dans le temps, et ne peut être lu par l'ordonnanceur que si le contexte utilisateur ne change pas du tout entre le début de l'interruption et l'appel de l'ordonnanceur. Or, si l'ordonnanceur est appelé par un timer il y a toujours des trucs qui changent (comme pr) et le design d'un unikernel fait qu'on ne veut pas sauvegarder plein de registres inutilement pour les autres interruptions.

À mon sens, la solution idéale à ce problème est de sauvegarder le contexte au moment du callback et pas celui avant l'interruption. Dans gint, le callback d'une interruption est supposé être userland standard (contrairement à un signal Linux par exemple) donc si c'est possible je veux pouvoir interrompre un thread durant le callback d'une interruption. Dans cette idée, la prise de contrôle de l'ordonnanceur préemptif se passe comme ça : le flot normal du programme est interrompu pour entrer dans le noyau quand le timer underflow, le kernel rend la main où callback, et ensuite le callback re-rentre dans le noyau (puisqu'il utilisera atomic_begin()) pour sauvegarder le contexte et changer de thread. Ça ne permet pas pour autant à l'ordonnanceur préemptif de se faire interrompre si ton interruption a un niveau assez élevé (genre 15).

Et du coup...


Dans ce cas-là non, en sauvegardant au moment opportun (durant le callback) je n'ai pas besoin de tout sauvegarder durant l'interruption.


Le code de start.c qui appelle main() peut juste faire un gros join sur tous les threads entre la fin de main() et l'appel des destructeurs ?


Quand main() se termine on retourne déjà automatiquement dans l'initialisation (le bootstrap) puisque c'est là que main() est appelée. Le code de construction/destruction et la fonction main() ne s'exécutant jamais en parallèle, pourquoi les séparer en plusieurs threads ?


Ce problème est résolu en considérant gint_switch() non comme un changement de thread mais comme un changement de world pour le thread courant. Je suppose qu'on peut avoir plusieurs threads dans l'OS d'ailleurs, c'est juste qu'absolument aucune fonction n'est prévue pour donc ça n'a pas vraiment d'intérêt (les threads de calcul pur peuvent rester dans gint).

Conclusion


De tout ce que je vois, ça passe dans le modèle que je présente. Cela dit, pour qu'on puisse progresser, il faut séparer le processus en quelques phases :

1. Fixer ce qu'on veut faire (cahier des charges)
2. Définir et valider un modèle
3. Implémenter et tester le modèle
4. Créer les applications

Ici j'ai attaqué 1 et 2. On n'est pas très loin dans le brainstorming sur ce sujet, donc ce n'est pas trop tard pour continuer à ajuster le cahier des charges, mais je pense qu'on aura vite fait le tour (à toi de voir). Une fois que ce sera le cas il faudra se concentrer sur la suite.

---

Citer : Posté le 15/01/2021 15:45 | #

---

Voilà, c'est comme ça que je le vois aussi !


Pas besoin d'environnement, mais oui il faut bloquer les interruptions. Pour correctement identifier ce qui doit être isolé et quelles conditions sont nécessaires, c'est bien de pas plonger tout de suite dans le code et de faire un peu de raisonnement.

Ce qu'on veut protéger c'est l'ensemble des fonctions ininterruptibles (« noyau »). Par construction, bloquer les interruptions suffit à garantir que le code ne soit pas interrompu. On n'a pas besoin (et on ne veut pas) bloquer les TLB miss et les exceptions génériques puisque tout le code est interruptible par ces deux choses-là. D'où IMASK=15.

On veut aussi garantir une certaine sémantique sur atomic_begin() end atomic_end(), en particulier que atomic_end() restaure SR exactement à son état du atomic_begin(), ce qui n'est pas juste IMASK=0 (en particulier si par malheur on imbrique deux fonctions atomiques). Donc il faut garder la trace à la fois du nombre d'imbrications et du IMASK d'origine, qui peut être à une valeur non-nulle durant un callback de timer. Ça nous donne un truc comme :


Pour ce qui est de la liste des régions concernées, il n'y en a pas beaucoup (du tout). Voici une liste détaillée à la façon de attributes(7). Les accès à l'initialisation ne sont pas comptés parce que les threads ne seront pas activés à ce moment-là (le timer ordonnanceur de la lib de threads n'aura pas de contrôle tant que le world gint ne sera pas initialisé). Je note hwrace les fonctions qui sont MT-Unsafe à cause d'accès au hardware ; pour ceux-là je laisse l'utilisateur se démerder pour synchroniser ses affaires.

Dans l'ensemble, le but n'est pas d'exposer une API MT-Safe dans la plupart des cas. En réalité, si tu fais des threads ton programme sera structuré de façon à ne pas faire d'accès concurrents dès le début (tu n'auras pas 3 threads de dessin). Le véritable besoin c'est :

1. De préserver la sémantique actuelle, c'est-à-dire que le code actuel ne puisse pas crasher en présence d'un second threads qui fait que tourner en boucle ;
2. Dans certains cas seulement, de définir et supporter une sémantique MT-Safe, pour faciliter le job de quelqu'un qui code en multi-threadé.

Voici une liste détaillée des propriétés de l'implémentation actuelle. Les ":here:" dénotent les endroits où il y a des améliorations.

Drivers
• cpg: MT-Safe (tout est en lecture seule ; sera MT-Unsafe hwrace avec l'overclocking)
• dma: MT-Unsafe hwrace (un poil gênant pour les memcpy() et memset() accélérés qui utilisent toujours le channel 1)
dma_transfer_noint() devrait borderline être ininterruptible, l'ordre des flags actuel (DE, TE, AE, NMIE) est safe mais mieux vaut protéger
• intc: MT-Unsafe hwrace (paramétrage des priorités)
• mmu: MT-Unsafe const (quasiment MT-Safe donc)
• r61524: Peut-être ininterruptible si l'écran supporte pas qu'on le fasse attendre, MT-Unsafe hwrace sinon
• rtc: MT-Safe sur l'accès à l'heure, MT-Unsafe hwrace sur le timer RTC
• spu: MT-Safe (pour l'instant)
• t6k11: Probablement ininterruptible
• tmu: MT-Unsafe hwrace
timer_reload() est ininterruptible si on change aussi TCNT
timer_start() et timer_stop() ont quelques passages ininterruptibles

Autres parties du noyau
Le world switch est ininterruptible (évidemment), et le world OS aussi (sauf UBC, éventuellement timer mais de préférence UBC seulement)
Le panic supporte les interruptions, mais devrait désactiver les interruptions qu'il ne veut pas ; subtil, à étudier
• MT-Unsafe race sur les contenus de la VBR et le paramétrage des interruptions
• Les threads ne doivent pas être utilisés avant la fin des constructeurs, ce qui est bon tant que tu as pas un constructeur qui crée des threads

Bibliothèques
• gray: MT-Unsafe (accès la VRAM, au mode de dessin global, aux délais)
Je planifie de modifier le dessin pour pouvoir dessiner sur des surfaces quelconques, ce qui évitera le race
gray_start() est ininterruptible (à protéger), gray_stop() aussi (mais c'est bon parce que timer_pause() l'est)
gray_int() doit être ininterruptible aussi, on peut juste demander une interruption atomique
• render: MT-Unsafe (accès VRAM et des états globaux)
• std: MT-Safe dans la plupart des cas, MT-Unsafe pour printf() (globales)
printf() devrait être MT-Safe


Ça j'y ai touché de loin dans mon post précédent, mais en fait ce n'est pas nécessaire. Ça se voit en deux étapes :

1. On a besoin de pouvoir interrompre des callbacks, ne serait-ce que pour faire tourner le moteur de gris pendant un callback un peu long.
2. Si le callback utilise atomic_begin() et atomic_end(), ce n'est pas grave s'il y a une petite fenêtre interruptible.

Imaginons qu'un callback normal se fasse interrompre entre son appel et sa première instruction, par le moteur de gris ou par l'ordonnanceur. Aucun problème : le thread est à ce moment-là en userland, il a « simplement » les données laissées par le gestionnaire d'interruption dans sa pile. Le changement de thread sauvegarde SR et r15 et tout ce qui va avec donc le nouveau thread ne sera pas affecté cet état. Lorsqu'on reviendra dans le thread, on arrivera direct dans le callback avec le SR du callback (qui a un IMASK égal au niveau de l'interruption l'ayant provoqué), la fonction s'exécutera, et à la fin on remontera la pile pour retourner dans le gestionnaire d'interruption. D'une certaine façon, le gestionnaire d'interruption est interruptible durant le callback, mais ça c'est voulu et prévu.

Quant à l'ordonnanceur lui-même, il est supposé avoir une priorité maximale pour qu'il ne puisse pas se faire interrompre. Faut voir après si le moteur de gris et de son (si ça existe) ne seraient pas plus importants.

Je n'ai pas d'opposition particulière à implémenter des callbacks atomiques, mais moins il y a de choses atomiques et mieux c'est, pas mal de modules en dépendent ou en dépendraient (moteur de gris, communication 3-pin ou USB, écran, son) et il vaut mieux que le système soit le plus réactif possible (en ce sens je contredis un peu l'assertion précédente que « on ne fait pas un RTOS » : on fait un peu un RTOS dès qu'on essaie de maintenir une bonne réactivité dans les situations où les performances sont limite).


Exactement. Pour l'instant les contextes sont alloués dans la section .gint.bss qui est en gros de la RAM statique. Je pense que la bonne façon de généraliser ça et d'allouer dynamique dans la RAM statique.

Je réfléchis à deux options, mais on en gros on peut soit faire un allocateur naïf qui ne libère jamais la mémoire, soit réfléchir à un design d'allocateur intelligent qu'on pourrait ensuite étendre pour faire des tas custom dans l'ILRAM ou autre. Cet allocateur intelligent pourrait gouverner aussi le tas de l'OS en utilisant le malloc() de l'OS à cet endroit. Ça résoudrait une partie des problèmes de l'allocation dynamique qu'on a actuellement.

Une fois que ça c'est fait la suite est pas trop dure, chaque driver a son ctx_size donc on peut créer des contextes à la volée. Le but original était d'ailleurs de stocker les contextes sur la pile lors du passage de gint à l'OS.


Le gestionnaire de mondes ne contient guère que ces quelques fonctions pour changer de monde donc ce serait difficile (ou pas très intéressant) de le séparer du gestionnaire de drivers. Mais ce n'est qu'un détail interne.

Pour ce qui est d'écraser le gestionnaire de mondes, je préfère quand c'est possible avoir des options et des callbacks plutôt que remplacer du code. La raison est que ça explicite les interactions et ça permet de mieux maintenir le code quand c'est possible. De plus, dans le cas de la lib threads et du traceur, c'est toi qui appelera le gestionnaire de mondes pour faire la transition, donc tu peux toujours ajouter le code que tu veux avant et après. Je ne me souviens pas qu'on ait évoqué de modifier le comportement de base de recharger les drivers (à part peut-être de préserver quelques drivers). Est-ce que j'ai raté quelque chose ? Est-ce que tu peux préciser ce que tu voudrais faire au gestionnaire de mondes pour voir s'il y aurait une API acceptable pour ça ?


L'ordonnanceur n'a pas besoin de créer le premier thread ; gint le crée. Tes structures de données peuvent être initialisées directement sans faire de saut. Tu peux voir ça comme « gint te donne le premier thread, tu crées les autres ». Le runtime de gint te fournit de quoi arrêter tous les autres threads avec des join dans un destructeur. Actuellement le mécanisme de gint_restart est un peu vite fait, en réalité ce serait mieux de mettre les constructeurs/destructeurs dedans. Je n'ai pas tous les détails en tête mais je ne vois pas où ça planterait dans le principe.


Le mécanisme de redémarrage n'était pas très solide, peut-être qu'on peut regarder là en premier lieu du coup.


Je pense qu'il ne peut y avoir que des intérêts à avoir une libc plus riche. L'allocation dynamique dont je parle plus haut est un point qui nous manque, la libc en est un autre. Il y a toujours la possibilité de la porter, mais on a eu un succès mitigé avec newlib alors...

Je déplacerais volontiers mes fonctions de gint vers la nouvelle lib. Pour l'instant je ne me suis pas précipité simplement parce qu'on n'a pas encore bien posé le cadre : tu parlais dans les derniers messages de viser un style glibc, qui ne me paraît pas forcément opportun, et les mécanismes de compilation/intégration n'étaient pas tout à fait clairs pour moi. C'est peut-être le bon moment d'en parler.

---

Citer : Posté le 18/01/2021 23:10 | #

---

Ce n'est pas une bataille, c'est juste un sujet compliqué avec beaucoup de points tordus...

---