Je suis d'accord avec Pascal sur le fait de laisser le scheduler organiser les process. J'avais fait quelques benchs sur un pSeries (Power4+) avec DLPAR et le fameux "CPU affinity" et ca donnait de moins obn resultats pour des databases. Par compte, c'est possible qu'en HPC ca change la donne mais la machine n'avait que 4CPU et 2 lpar. Seule celle en AIX 5.2 pouvait supporter cette option, l'autre en SLES8/Pseries ne m'offrait aucune option.
On Sat, 13 Nov 2004, Pascal Bleser wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Fabian Vilers wrote: > | BOnjour à tous, > Salut Fabian > > | Imaginons une machine a plus d'un CPU. Est-il possible de dédier le CPU #0 > | pour les tâches "système" et le #1 pour les tâches "utilisateur"? C'est une > | question d'intérêt général, je ne possède malheureusement pas ce genre > | d'équipement. > > Ca s'appelle du CPU "pinning" (to pin = attacher). > C'est qqe chose qui est possible avec quelques OS (comme Solaris ou AIX > (AFAICR)) mais pas avec > Linux... 2.4 en tout cas. > Tout comme Alain, il me semble aussi avoir vu qqe chose de ce genre pour le > kernel 2.6 -> voir "CPU > affinity". > > En gros, du moins pour le kernel 2.4, les développeurs kernel disaient que ce > n'était pas qqe chose > de très intéressant quand on y réfléchit bien, étant donné que si tu ne fais > pas de "pinning", le > scheduler sait répartir les tâches de manière bien plus optimale que si tu le > forces à mettre tel ou > tel processus sur tel ou tel processeur. > En outre, il est plus "coûteux" (en terme de ressources et de performances) > de faire passer une > tâche d'un processeur à un autre. Le scheduler Linux est au courant de ce > fait, et gère les > processeurs et la distribution des tâches sur ceux-ci en fonction. > > Bref, c'est p-e disponible avec le kernel 2.6, mais définitivement pas avec > 2.4. > Et puis c'est loin d'être aussi intéressant qu'il n'y paraît au premier > abort: il vaut mieux laisser > faire le scheduler comme il l'entent, plutôt que de lui forcer la main. > > La raison pour laquelle cette fonction est disponible p.ex. sur Solaris, > c'est surtout par rapport > au Sun Enterprise 15000, dans lesquelles on trouve généralement 64 > processeurs, en vue de faire du > "partitionnement", càd avoir une très grosse machine qu'on peut logiquement > diviser en plusieurs > plus petites - en gros la stratégie inverse de Linux, qui serait plutôt: > beaucoup de petites > machines, et quand on a besoin de plus, il suffit d'ajouter qqes "petites" > machines au cluster/grid, > plutôt que d'acheter plus de CPUs ou une 2ème E15000. > Pour la petite histoire, les E15K se vendent encore pas trop mal mais sont > plutôt en perte de > vitesse en faveur de ... devine... une stratégie de "petites" (*) machines > Linux, stratégie qui est > beaucoup poussée par IBM et Oracle, notamment. > > (*) faut pas rire hein, les "petites" machines, ce sont plutôt des 4 CPUs / > 4GB RAM, ou 2 CPUs avec > HyperThreading (+ou- = 4), on encore des 2xAMD64 (4xAMD64 est encore assez > peu courant) > > | Bon week-end, > Egalement ;) > > - -- > ~ -o) Pascal Bleser http://guru.unixtech.be > ~ /\\ <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > ~ _\_v The more things change, the more they stay insane. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.2 (GNU/Linux) > > iD8DBQFBlj48r3NMWliFcXcRAnttAJwKmKXo40eNbjV4GFnMyCA/KtKZqgCfXDpV > MvFBiCFSHlfRILLuDqoMBUc= > =wALC > -----END PGP SIGNATURE----- > _______________________________________________________ > Linux Mailing List - http://www.unixtech.be > Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux > Archives: http://www.mail-archive.com/linux@lists.unixtech.be > IRC: chat.unixtech.be:6667 - #unixtech > _______________________________________________________ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/linux@lists.unixtech.be IRC: chat.unixtech.be:6667 - #unixtech
