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
Lorigine 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
Larchitecture matérielle
Processeur
Processeur
Processeur
Processeur
Bus Système
Mémoire
Contrôleur Entrée - Sorties
Contrôleur Mémoire
Vers le bus dentrée - sorties (ex PCI )
7
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)

8
Impact sur le logiciel
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
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 109 itérations (monothread),
• Test2 boucle de 106 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 109 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.