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/[email protected] > 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/[email protected] IRC: chat.unixtech.be:6667 - #unixtech
