> Apres y a surrement quelques subtilités à regler, mais j'imagine que l'essentiel est fait très tot.
Ouais, quelques subtilités, comme tu dis ;-)
Pour des applications fesant du calcul pur, effectivement, la question est relativement facile à régler au niveau de l'OS. C'est au niveau applicatif qu'il faut paralléliser les algos.
Maintenant, si tu prends une application comme un gros SGBD, ou quelque chose qui utilise beaucoup d'appels systèmes, tu passes facilement 20% du temps dans les couches noyau. Maintenant, tu imagines bien que si deux processeurs executent en parallèle deux bouts de code qui touchent au mêmes données, ou au même périphérique, tu as 99% de chances d'avoir un truc déconnant. Il faut donc placer des verrou pour assurer l'exclusion mutuelle de certaines portions de code dans le noyau. L'approche la plus simple (c'est en gros comme ça que ça se passait dans les premiers Linux SMP), c'est de mettre un gros verrou sur l'ensemble du noyau, ce qui fait que deux processeurs ne peuvent pas executer du code en mode noyau en même temps. Ca marche assez bien sur 2 processeurs, parce que pendant qu'un processeur execute du code dans le noyau, l'autre processeur a en général un processus à executer. Mais évidement, si tu passes 20% du temps dans le noyau, et que tu as plus de 5 processeurs, alors tu as toujours plusieurs processeurs qui n'ont rien à faire. C'est (entre autres) pour ça qu'un Linux 2.2 a du mal sur une machine quadri-proc, et n'arrive vraiment pas à utiliser correctement 8 procs.
Pour utiliser correctement un grand nombre de processeurs, il faut donc que les verroux d'exclusion mutuelle dans le noyau soient le plus fins possibles. Qu'un processeur puisse écrire sur un disque dur pendant qu'un autre écrit sur un autre disque par exemple. Il y a déjà eu beaucoup de progrès dans ce domaine depuis Linux 2.2, mais avant d'exploiter correctement 1024 processeurs, il y a encore du boulot !
Ce n'est bien sur pas le seul problème. Par exemple, quand le noyau doit choisir entre 5 ou 10 processus éligibles (ce qui correspond déjà à une machine très chargée pour un mono ou bi-processeur), tu t'en fout pas mal que l'algo de scheduling soit en O(n), O(log(n)) ou en O(1). Sur une machine 1024 procs, tu as au moins 1024 taches éligibles à chaque instant quand ta machine est chargée, et la, la finesse des algos fait la différence.
Bref, avoir un systeme qui tourne sur 1024 procs, c'est assez facile, mais avoir un des perfs acceptables sur un tel système (avoir un système qui n'est pas trop loin d'être 1024 fois plus rapide qu'un système mono-processeur), c'est une autre paire de manches !
[^] # Re: Petite question
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Linux devient massivement multiprocesseurs. Évalué à 10.
Ouais, quelques subtilités, comme tu dis ;-)
Pour des applications fesant du calcul pur, effectivement, la question est relativement facile à régler au niveau de l'OS. C'est au niveau applicatif qu'il faut paralléliser les algos.
Maintenant, si tu prends une application comme un gros SGBD, ou quelque chose qui utilise beaucoup d'appels systèmes, tu passes facilement 20% du temps dans les couches noyau. Maintenant, tu imagines bien que si deux processeurs executent en parallèle deux bouts de code qui touchent au mêmes données, ou au même périphérique, tu as 99% de chances d'avoir un truc déconnant. Il faut donc placer des verrou pour assurer l'exclusion mutuelle de certaines portions de code dans le noyau. L'approche la plus simple (c'est en gros comme ça que ça se passait dans les premiers Linux SMP), c'est de mettre un gros verrou sur l'ensemble du noyau, ce qui fait que deux processeurs ne peuvent pas executer du code en mode noyau en même temps. Ca marche assez bien sur 2 processeurs, parce que pendant qu'un processeur execute du code dans le noyau, l'autre processeur a en général un processus à executer. Mais évidement, si tu passes 20% du temps dans le noyau, et que tu as plus de 5 processeurs, alors tu as toujours plusieurs processeurs qui n'ont rien à faire. C'est (entre autres) pour ça qu'un Linux 2.2 a du mal sur une machine quadri-proc, et n'arrive vraiment pas à utiliser correctement 8 procs.
Pour utiliser correctement un grand nombre de processeurs, il faut donc que les verroux d'exclusion mutuelle dans le noyau soient le plus fins possibles. Qu'un processeur puisse écrire sur un disque dur pendant qu'un autre écrit sur un autre disque par exemple. Il y a déjà eu beaucoup de progrès dans ce domaine depuis Linux 2.2, mais avant d'exploiter correctement 1024 processeurs, il y a encore du boulot !
Ce n'est bien sur pas le seul problème. Par exemple, quand le noyau doit choisir entre 5 ou 10 processus éligibles (ce qui correspond déjà à une machine très chargée pour un mono ou bi-processeur), tu t'en fout pas mal que l'algo de scheduling soit en O(n), O(log(n)) ou en O(1). Sur une machine 1024 procs, tu as au moins 1024 taches éligibles à chaque instant quand ta machine est chargée, et la, la finesse des algos fait la différence.
Bref, avoir un systeme qui tourne sur 1024 procs, c'est assez facile, mais avoir un des perfs acceptables sur un tel système (avoir un système qui n'est pas trop loin d'être 1024 fois plus rapide qu'un système mono-processeur), c'est une autre paire de manches !