> On leur a expliqué que le SMP était quand même une technologie pas trop nouvelle ?

Pas sûr qu'ils aient les capacités de comprendre (moi, méchant ? Juste un peu :) ).

De plus, les processeurs multicores existent déjà depuis pas mal d'années chez IBM, par exemple. Il se trouve juste qu'aujourd'hui, les processeurs grand-public vont utiliser ce principe pour améliorer les performances en environnements multitâches/multithreadés afin de compenser les difficultés actuelles des fondeurs à faire monter leurs puces en fréquence.

Ensuite, il y a plusieurs façons de faire la liaison interprocesseur, qui ne dépend que de la technologie déjà utilisée sur les gammes modifiées. Par exemple, sur les P4 d'Intel, le gain par arpport à une solution avec 2 processeurs distincts est très faible, car les processeurs se partagent un bus externe (ou un truc du genre), alors que les Athlon 64 d'AMD sont reliés, comme sur une solution à 2 processeurs, par un bus HyperTransport(TM), mais interne, ce qui améliore un chouia plus les performances du bicore.
En ce qui concerne l'amélioration des performances, je doute qu'il y ait quoique ce soit de particulier à faire au niveau du gestionnaire de processus noyau, mais bon, je n'y connaît pas grand'chose en SMP.

Salut,

D'après ce que j'ai compris, l'ordonnanceur du noyau dispose déjà d'un mécanisme appellé «scheduling domains», qui permet de prendre en compte la répartition des coeurs dans un systèmes : sur une même puce, sur deux puces différentes dans la même machine, sur des puces différentes dans des machines différentes (NUMA). Et en fonction de ça, l'ordonnanceur peut optimiser le placement des threads. Ainsi, au lieu de changer brutalement un thread d'un processeur à un autre, il peut essayer de le conserver dans le même processeur, pour bénéficier des effets de cache communs dans une architecture multi-coeur.

Voir paragraphe 5.7.2 de http://josh.trancesoftware.com/linux/linux_cpu_scheduler.pdf(...)

Thomas