L'architecture multiprocesseurs sous Linux

L'architecture multiprocesseurs sous Linux

Alain Rouen - IR5

PlanRappel historique sur les systèmes

multiprocesseurs,Architecture matérielle,Impact sur le logiciel,Le "Symetric Multiprocessor" sous Linux.

L’origine des systèmes multiprocesseursIls 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 MultiProcessorsLe 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

ContrôleurEntrée - Sorties

ContrôleurMémoire

Vers le busd’entrée - sorties

(ex: PCI )

Bus Système

Mémoire

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

Impact sur le logiciel

File d'attentedes 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

Ordonnancement sur un système monoprocesseur

T1 T2 T3

Impact sur le logiciel

File d'attentedes processus • P1• P2• …• Pn

Ordonnancement et exécution

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

Ordonnancement sur un système multiprocesseurs

Py T1 Py T2 Py T3

Processeur 1 : Processus x

...Processeur n : Processus y

Px T1 Px T2 Px T3

Impact sur le logicielLe 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 logicielImpact 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 LinuxLinux 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 LinuxLe 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 LinuxPour 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

BenchmarkTests Temps moy. SMP (s) Temps moy. NOSMP (s) Gain (%)Test1 (loop1) 11,9 11,42 -4,20Test2 (loop2) 3,25 3,03 -7,26Test3 (loop1) 31,2 44,8 30,36Test3 (loop2) 14 17,53 20,14Test4 (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.

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