Développement de noyaux pour supporter plusieurs processeurs

Question

Je cherche à entrer dans le développement du noyau du système d'exploitation et j'ai pensé que ma contribution serait d'étendre le système d'exploitation SANOS afin de supporter plusieurs machines principales. J'ai lu des livres sur les systèmes d'exploitation (Tannenbaum) et étudié comment BSD et Linux ont relevé ce défi, mais je suis toujours coincé sur plusieurs concepts.

1. Est-ce que SANOS besoin d'algorithmes d'ordonnancement plus sophistiqués quand il fonctionne sur plusieurs processeurs ou sera ce qui est actuellement en place fonctionne bien? Je sais que c'est une bonne idée pour les threads d'avoir une affinité avec un noyau sur lequel ils ont été démarrés, mais est-ce géré par la planification ou en modifiant l'implémentation de la façon dont les threads sont créés?

2. Que faudrait-il considérer de telle sorte que SANOS puisse fonctionner sur une machine avec des centaines de cœurs? D'après ce que je peux dire, BSD et Linux ne supportent au mieux qu'un maximum d'une douzaine de cœurs.

Answer 1

Votre matériel de lecture est bon. Donc pas de problèmes là-bas. Jetez aussi un coup d'œil aux conférences CS téléchargeables sur la conception de systèmes d'exploitation de Stanford.

1. L'algorithme de planification peut avoir besoin d'être plus sophistiqué. Cela dépend des types d'applications en cours d'exécution et de leur gourmandise. Est-ce qu'ils se rendent ou sont-ils obligés de le faire? Ce genre de chose. C'est plus une question de ce que vos processus veulent, ou attendent. Un RTOS aura une planification plus complexe qu'un ordinateur de bureau.
2. Les threads doivent avoir une affinité avec un cœur, car 2 threads dans un processus peuvent s'exécuter en parallèle ... mais pas au même moment en temps réel sur le même cœur. Les mettre sur des noyaux différents leur permet de vraiment fonctionner en parallèle. La mise en cache peut également être optimisée pour l'affinité de base. C'est vraiment un mélange de votre implémentation de thread et de votre planificateur. Le sched peut vouloir s'assurer que les threads sont démarrés en même temps sur les cœurs, plutôt qu'ad hoc pour réduire le temps d'attente des threads les uns sur les autres et sur les choses. Si votre bibliothèque de threads est un espace utilisateur, elle affecte peut-être le core ou permet au planificateur de décider en fonction de la capacité ou des décès récents.
3. L'évolutivité est souvent une limite de noyau (qui peut être arbitraire). Sous Linux, si je me souviens bien, les limites sont dues au dimensionnement statique des tableaux qui contiennent les structures d'information du processeur dans le planificateur. Par conséquent, ils sont de taille fixe. Cela peut être changé en recompilant le noyau. La plupart des bons algorithmes d'ordonnancement supporteront un très grand nombre de cœurs. Au fur et à mesure que votre nombre de processeurs ou de processeurs augmente, vous devez veiller à ne pas trop fragmenter l'exécution des processus. Si un programme a 2 threads, essayez de les planifier dans le proche-temps, car une causalité peut exister (par l'intermédiaire de données partagées) entre eux.

Vous devez également décider comment vos threads sont implémentés et comment un processus est représenté (lourd ou léger) dans le noyau. Le noyau des threads est-il géré? l'espace utilisateur est-il géré? Toutes ces choses ont un impact sur la conception du planificateur. Regardez comment les threads POSIX sont implémentés dans différents systèmes d'exploitation. Il y a tellement de choses auxquelles vous devez penser :)

en bref Il n'y a pas vraiment de réponses directes à l'endroit où la logique se situe ou devrait résider. Tout dépend de la conception, des attentes de l'application, des contraintes de temps (sur les programmes) et ainsi de suite.

J'espère que cela aide, je ne suis pas un expert ici cependant.