L'architecture

multiprocesseurs sous Linux

Alain Rouen - IR5

 Plan

 Rappel historique sur les systèmes

multiprocesseurs,
 Architecture matérielle,
 Impact sur le logiciel,
 Le "Symetric Multiprocessor" sous Linux.
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.
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.
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…
L’architecture matérielle

Processeur Processeur Processeur Processeur

Bus Système

Contrôleur Contrôleur
Entrée - Sorties Mémoire Mémoire

Vers le bus
d’entrée - sorties
(ex: PCI )
Les limites de l'architecture SMP
 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)
 Impact sur le logiciel
Ordonnancement sur un système monoprocesseur
File d'attente Ordonnancement et exécution
des processus
• P1
•… T1 T2 T3
• Pn

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
 Impact sur le logiciel
Ordonnancement sur un système multiprocesseurs
File d'attente Ordonnancement et exécution
des processus Processeur 1 : Processus x
• P1 Px T1 Px T2 Px T3
• P2 ...
•… Processeur n : Processus y
• Pn 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
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).
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).
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).
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...
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.
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
Benchmark
Tests Temps moy. SMP (s) Temps moy. NOSMP (s) Gain (%)
Test1 (loop1) 11,9 11,42 -4,20
Test2 (loop2) 3,25 3,03 -7,26
Test3 (loop1) 31,2 44,8 30,36
Test3 (loop2) 14 17,53 20,14
Test4 (loop3) 12 22,85 47,48

 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.
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.