L'architecture multiprocesseurs sous Linux

1. L'architecture multiprocesseurs sous Linux Alain Rouen - IR5

2. Plan • Rappel historique sur les systèmes multiprocesseurs, • Architecture matérielle, • Impact sur le logiciel, • Le "Symetric Multiprocessor" sous Linux.

3. L’origine des systèmes multiprocesseurs • Ils sont apparus durant les années 1960 avec les systèmes mainframe haut de gamme, • C'est le besoin de scalabilité qui a conduit les concepteurs de systèmes à adopter cette approche, • La scalabilité est la propriété qui rend possible d'adapter un système aux dimensions du problème à traiter.

4. La performance à coût modéré • La puissance de traitement est ajustée au besoin par l'installation du nombre approprié de processeurs, Il s'agit de la façon la plus économique d'offrir la scalabilité, • L'investissement se limite à l'achat de nouveaux processeurs et non pas d'un nouveau système.

5. Symetric MultiProcessors Le SMP se caractérise par une architecture « en couplage serré » : tous les processeurs peuvent accéder à toutes les ressources du systèmes, Un seul système d'exploitation gère l'ensemble des ressources du système. Le matériel nécessite donc de prendre en compte des problèmes de parallélisme : accès mémoire, cohérence du cache, i/o…

6. L’architecture matérielle Processeur Processeur Processeur Processeur Bus Système Mémoire Contrôleur Entrée - Sorties Contrôleur Mémoire Vers le bus d’entrée - sorties (ex: PCI )

7. Limitation du nombre de processeur en raison des conflits d'accès au niveau matériel (bus) et logiciel (système d'exploitation) : environ 8 processeurs pour les systèmes peu onéreux (Intel), de 16 à 128 processeurs pour des architectures complexes et onéreuses (Sun, IBM, HP). Complexité du matériel (chipset controleur i/o et mémoire) Les limites de l'architecture SMP

8. Impact sur le logiciel T1 T2 T3 Ordonnancement sur un système monoprocesseur File d'attente des processus • P1 • … • Pn Ordonnancement et exécution L'ordonnanceur traite les processus les uns après les autres • T1 : Chargement de contexte du processus Px, • T2 : Traitement partiel du processus Px, • T3 : Sauvegarde du contexte du processus Px, • T1 + T2 + T3 : Cycle de l'ordonnanceur

9. Impact sur le logiciel Px T1 Px T2 Px T3 Ordonnancement sur un système multiprocesseurs File d'attente des processus • P1 • P2 • … • Pn Ordonnancement et exécution Processeur 1 : Processus x ... Processeur n : Processus y Py T1 Py T2 Py T3 L'ordonnanceur traite autant de processus qu'il y a de processeurs • T1 : Chargement de contexte d'un processus, • T2 : Traitement d'un processus, • T3 : Sauvegarde du contexte d'un processus, • T1 + T2 + T3 : Cycle de l'ordonnanceur

10. Impact sur le logiciel Le SMP permet donc d'augmenter le débit de l'ordonnanceur, mais pas de réduire le temps d'exécution d'un processus donné, Impact sur les applications : Le traitement simultané de plusieurs processus induit des conflits d'accès aux ressources, Un processus monothread s'exécutera donc, au mieux, aussi rapidement que sur un système monoprocesseur, Si un processus est multithread, son traitement peut fortement s'accélérer (parallèlisation du traitement).

11. Impact sur le logiciel Impact sur le système d'exploitation : Pour tirer profit des capacités du SMP, le noyau doit être fondé sur le concept de thread. Ainsi on augmente l'efficacité de la commutation thread à thread, Il est nécessaire d'utiliser des mécanismes de verrous pour gérer les conflits d'accès aux ressources. Il est nécessaire d'utiliser des verrous adaptés aux besoins du système (taille du verrouillage).

12. Le SMP sous Linux • Linux supporte le SMP depuis le noyau 2.0, mais, ce support est réellement efficace depuis le noyau 2.2, • Depuis le kernel 2.2, les processus et les threads du noyau sont répartis entre les processeurs. • La version 2.2 du noyau possède une gestion des signaux, des interruptions et de quelques E/S à verrouillage fin (fine grain locking).

13. Le SMP sous Linux • Le prochain noyau (2.4) possédera vraiment des verrous noyaux fins, • Tous les sous-systèmes majeurs du noyau 2.4 sont complètement codés avec des threads : réseau, VFS, VM, ES, block/pages de cache, ordonnancement, interruptions, signaux, etc...

14. Programmation SMP sous Linux • Pour tirer profit du SMP, il faut exploiter le concept de mémoire partagée, • Seuls les threads POSIX fournissent des threads multiples partageant certaines ressources telles la mémoire, • Les LinuxTheads, intégrés dans la glibc2, mettent en œuvre des threads au niveau kernel permettant d'exploiter pleinement le SMP.

15. Benchmark • Description des tests : • Test1 : boucle de 10^9 itérations (monothread), • Test2 : boucle de 10^6 itérations, avec une lecture de fichier (primitive read() sur /dev/zero et monothread), • Test3 : lancement simultané de Test1 et Test2 (commande shell, programme monothread), • Test4 : deux boucles de 10^9 itérations chacune (programme multithread), • Mesure du temps d'exécution avec la commande time. • Plateforme de test : kernel Linux 2.2.17 et Bi-Pentium II 350 et la glibc 2.1.3, gcc 2.95

16. Benchmark • On constate : • un gain nul, voir négatif, pour les programmes monothread lancés en mode SMP, • un gain de 20 à 30 % pour des programmes monothread lancés simultanément : le kernel SMP distribue le traitement vers les différents CPU, • un gain de 47 % pour un programme multithread lancé en mode SMP.

17. Conclusion • Le SMP sous Linux apporte réellement un gain de performance, à condition d'utiliser le plus possible une approche multithread lors de futur développement; les programmes multithread restant totalement compatible avec les systèmes non SMP, • Le futur kernel 2.4 améliorera encore le support du SMP.