Re: [linux] CPU From 8 2 2
bonsoir, je n'ai pas encore testé mais tu pourrais essayer l'argument suivant lors du boot : maxcpus=[SMP] Maximum number of processors that an SMP kernel should make use of On Fri, 2007-03-09 at 09:44 +0100, Thierry Leurent wrote: > Bonjour, > > Quel sujet étrange que voila > J'ai un serveur dual-xeon dual-cores hyperthreadés (2 * 2 * 2 = 8 CPU dans > /proc/cpuinfo) > J'ai un soft commercial qui refuse de lancer parce qu'il à une license 2 > CPU :(. > Bon c'est vrai, quand le vendeur à demandé combien de CPU avez-vous on a > dit 2 et on n'a pas menti. Et j'ai pas la possibilité de le virer. > > Existerait-il une solution pour diminuer le nombre de CPU ? > > Je suis sous RHEL 4 avec un kernel est un 2.6.9. > > > Merci > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://lists.unixtech.be/cgi-bin/mailman/listinfo/linux Archives: http://www.mail-archive.com/linux@lists.unixtech.be IRC: chat.unixtech.be:6667 - #unixtech NNTP: news.gname.org - gmane.org.user-groups.linux.unixtech
Re: [linux] CPU From 8 2 2
Le 10/03/07, Jean-François Gobin<[EMAIL PROTECTED]> a écrit : Créer un environnement virtuel et n'y attacher que 2 instances processeurs ? Installer RHEL5 quand elle sort (dans peu de temps), puis installer une instance de RHEL4.5 para-virtualisée et effectivement ne montrer que deux CPU. http://virt.108.redhat.com/ http://people.redhat.com/riel/RHEL4-Xen-HOWTO Cdt, J. -- Jérôme Fenal - jfenal AT gmail.com - http://fenal.org/ Paris.pm - http://paris.mongueurs.net/ ___ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://lists.unixtech.be/cgi-bin/mailman/listinfo/linux Archives: http://www.mail-archive.com/linux@lists.unixtech.be IRC: chat.unixtech.be:6667 - #unixtech NNTP: news.gname.org - gmane.org.user-groups.linux.unixtech
RE: [linux] CPU From 8 2 2
Créer un environnement virtuel et n'y attacher que 2 instances processeurs ? -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Thierry Leurent Envoyé : vendredi 9 mars 2007 9:44 À : linux@lists.unixtech.be Objet : [linux] CPU From 8 2 2 Bonjour, Quel sujet étrange que voila J'ai un serveur dual-xeon dual-cores hyperthreadés (2 * 2 * 2 = 8 CPU dans /proc/cpuinfo) J'ai un soft commercial qui refuse de lancer parce qu'il à une license 2 CPU :(. Bon c'est vrai, quand le vendeur à demandé combien de CPU avez-vous on a dit 2 et on n'a pas menti. Et j'ai pas la possibilité de le virer. Existerait-il une solution pour diminuer le nombre de CPU ? Je suis sous RHEL 4 avec un kernel est un 2.6.9. Merci -- Thierry Leurent E-mail : [EMAIL PROTECTED] Website (en developpement) : http://www.asgardian.be ___ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://lists.unixtech.be/cgi-bin/mailman/listinfo/linux Archives: http://www.mail-archive.com/linux@lists.unixtech.be IRC: chat.unixtech.be:6667 - #unixtech NNTP: news.gname.org - gmane.org.user-groups.linux.unixtech ___ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://lists.unixtech.be/cgi-bin/mailman/listinfo/linux Archives: http://www.mail-archive.com/linux@lists.unixtech.be IRC: chat.unixtech.be:6667 - #unixtech NNTP: news.gname.org - gmane.org.user-groups.linux.unixtech
[linux] CPU From 8 2 2
Bonjour, Quel sujet étrange que voila J'ai un serveur dual-xeon dual-cores hyperthreadés (2 * 2 * 2 = 8 CPU dans /proc/cpuinfo) J'ai un soft commercial qui refuse de lancer parce qu'il à une license 2 CPU :(. Bon c'est vrai, quand le vendeur à demandé combien de CPU avez-vous on a dit 2 et on n'a pas menti. Et j'ai pas la possibilité de le virer. Existerait-il une solution pour diminuer le nombre de CPU ? Je suis sous RHEL 4 avec un kernel est un 2.6.9. Merci -- Thierry Leurent E-mail : [EMAIL PROTECTED] Website (en developpement) : http://www.asgardian.be ___ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://lists.unixtech.be/cgi-bin/mailman/listinfo/linux Archives: http://www.mail-archive.com/linux@lists.unixtech.be IRC: chat.unixtech.be:6667 - #unixtech NNTP: news.gname.org - gmane.org.user-groups.linux.unixtech
Re: [linux] CPU
comme tu le dis pascal, ca en reviens a faire un bon design d'application, se qui est nettement plus difficile a faire pour une societe que de decider qu'il faut $beaucoup$ pour une solution que l'on achete a l'exterieur (comme ca on peut relancer la faute sur kk d'autre quand l'application mal foutue plantera). C'est exactement comme la securite, ou tu fais kkchose d'intelligent dans tes applications / OS ou tu achete ta securite avec des Firewall, des IDS., des IPS des anti virus spam worms truc machins et bidules, qui finalement ne resolvent pas grand chose, mais permettent de pouvoir relancer la faute sur le vendeur de matos. C'est beau l'informatique je trouve, enfin ce n'est pas unique a ce domaine. On Thu, Nov 18, 2004 at 07:50:16AM +0100, Pascal Bleser wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Thomas Silvestre wrote: > | Au boulot nous avons aussi ce genre de grsse machine, mais ?? part des > | disques et des ventilateurs et malgr?? un d??m??nagement de quelques km et > | une perte soudaine du courant dans toute la salle des serveur, nous > | n'avons jamais rencontr?? de probl??me hardware bloquant (a??e, je ne > | devrais pas dire ??a). Pour info nous utilisons du materiel ibm pSeries. > | Nous allons recevoir 2 nouveaux serveurs (p570) tr??s bient??t. > | Question maintenance et support, c'est vrai ??a co??te un pont. > | > | Petite question: avez-vous d??j?? eu de mauvaises exp??rience et avec quel > | mat??riel ou quel fabriquant? Des anecdotes c'est toujours sympa. > > Nous (ou nos clients) n'avons pas vraiment eu de mauvaises exp??riences > c??t?? stabilit?? ou m??me > performance, pour autant que je sache en tout cas. > > Moi c'est plut??t l'aspect du co??t que je voulais mettre en avant. > > Et en fait c'est assez simple ?? argumenter (en d??faveur des "grosses" > machines): > dans 99% des cas, tout le monde a un besoin en performances qui est assez > stable sur toute l'ann??e. > Il y a des peaks en journ??e, ou bien la nuit, mais grossomodo, c'est > mesur??, bien connu et puis on > sait acheter une machine (ou plusieurs) en fonction de cela. > Je vais prendre l'exemple d'un de nos clients, VISA. > Pour VISA comme dans la tr??s grande majorit?? des cas, il y a plusieurs > p??riodes de peaks tr??s forts > sur l'ann??e, comme p.ex. no??l, p??ques, la p??riode de vacances. > Pendant ces p??riodes-l??, tu as un besoin en performance qui est souvent 2 > ?? 3 fois sup??rieur ?? ton > maximum sur l'ann??e. > > Tout ceci pour expliquer que si tu prends pour strat??gie d'utiliser une > (ou deux) tr??s grosse(s) > machine(s) (disons une Sun Enterprise 15000), tu es forc??ment oblig?? > d'acheter une machine grosse > assez pour supporter la charge _maximale_ en production sur toute l'ann??e. > Or, elle va s'emmr le reste du temps. > > Si, par contre, tu choisis une strat??gie avec beaucoup (ou du moins > plusieurs) machines plus > "petites" (comme d??j?? dit, pas n??cessairement des P3 avec 256MB RAM non > plus hein ;)) que tu > utilises en cluster, tu gagnes: > 1) en redondance: lorsque des composantes mat??rielles rendent l'??me, une > autre machine reprend la > charge (oui, je sais, ces "grosses" machines ont quand m??me pas mal de > composants en redondance > (alimentation, ...) mais bon, quand m??me - essaye de couper une E15K en > deux pour la mettre sur 2 > sites ;)) > 2) en co??ts: lorsque tu as ces p??riodes "chaudes" sur l'ann??e, tu > ajoutes des machines pour g??rer la > charge - mais ces machines peuvent ??tre utilis??es pour d'autres > applications le reste de l'ann??e > 3) en maintenance: oui et non: > ~ - tu y perds ?? moins d'avoir des bons syst??mes de gestion de cluster > (g??rer 30 machines est ?? > priori plus complexe qu'en g??rer une seule, m??me partitionn??e) > ~ - tu y gagnes parce que quand tu veux augmenter la performance, tu > ajoutes qqes machines (p.ex. > Intel ou AMD + Linux) - avec ton E15K, une fois la capacit?? maximale > atteinte, il faudra en acheter > une 2??me (et bonjour les frais) > > N??anmoins, j'ajouterais un b??mol ?? ce que Jef ?? dit: c'est beaucoup > plus complexe d'impl??menter une > application qui fonctionne bien en termes de "scalability" (+/- > "parall??lisation") et de "failover" > qu'une application qui fonctionne simplement avec beaucoup de CPUs. Donc > ??a d??pend parfois aussi du > cas de figure, du type et de la qualit?? de l'impl??mentation (software). > Un cluster de serveurs web (p.ex. Apache ou Tomcat), ??a se g??re tr??s > facilement en cluster de > beaucoup de petites machines. Par contre, quand il y a beaucoup d'acc??s DB > et beaucoup de donn??es ?? > ~ g??rer, c'est d??j?? nettement plus compliqu?? (synchronisation des > sessions, des caches, ??viter la > s??rialisation des acc??s DB, XA est une horreur, ...). > Enfin, ??a fait vivre les architectes syst??me comme moi ;D > > Il faut aussi voir que tu dois investir dans un bon backbone en fibre > optique (ou myrinet) pour >
Re: [linux] CPU
ben j'en connais avec tous les vendeurs, mais perso c'est surtout des probs avec SUN. On Wed, Nov 17, 2004 at 11:02:18PM +0100, Thomas Silvestre wrote: > Au boulot nous avons aussi ce genre de grsse machine, mais ?? part des > disques et des ventilateurs et malgr?? un d??m??nagement de quelques km et > une perte soudaine du courant dans toute la salle des serveur, nous > n'avons jamais rencontr?? de probl??me hardware bloquant (a??e, je ne > devrais pas dire ??a). Pour info nous utilisons du materiel ibm pSeries. > Nous allons recevoir 2 nouveaux serveurs (p570) tr??s bient??t. > Question maintenance et support, c'est vrai ??a co??te un pont. > > Petite question: avez-vous d??j?? eu de mauvaises exp??rience et avec quel > mat??riel ou quel fabriquant? Des anecdotes c'est toujours sympa. > > -- > Thomas > > Le mercredi 17 novembre 2004 ?? 10:31 +0100, Alain EMPAIN a ??crit : > > > > Jean-Francois Dive wrote: > > > de toute facon les grosses caisses avec pleins de CPU c'est pas > > > interessant, ca coute chers et ca crashe tout le temps. > > > > Un petit exemple ? > > > > Une machine 64 CPUs de 3 ans; pas possible de se passer du contrat de > > maintenance car il est utilis?? r??guli??rement... > > > > La valeur annuelle de ce contrat de maintenance ??tait suffisante pour > > acheter CHAQUE ANNEE plus de deux fois la puissance CPU, l'espace RAM, > > l'espace HD sous forme de calculateurs dual-XEONS standards (32 bits), > > facilement r??parables, rempla??ables en cas de panne (ou additionnables > > d'ann??e en ann??e) ou min une fois avec des Opterons (64 bits). > > > > Ok, pour interconnecter les noeuds ?? plus de 1Gb/s c'est plus cher mais > > quand m??me c'est bien plus souple, robuste et extensible comme solution ! > > > > A la limite, pas de contrat de maintenance : avec cet argent on ach??te > > du nouveau mat??riel chaque ann??e (et on colle ?? la loi de Moore au lieu > > d'entretenir un vieux trigu) et on peut m??me se permettre de jeter > > froidement ce qui ne va plus, sans y regarder ;-) > > > > Bonne journ??e, > > > > Alain > > > > > > > Rien ne vaut un > > > bon cluster de PC et ca dois marcher pour toutes les applications si > > > elle est bien developee. > > > > > > On Tue, Nov 16, 2004 at 07:00:27AM +0100, Pascal Bleser wrote: > > > > > >>-BEGIN PGP SIGNED MESSAGE- > > >>Hash: SHA1 > > >> > > >>Vincent Jamart wrote: > > >>| 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. > > >> > > >>Oui, normal, SLES8 est sur kernel 2.4. > > >> > > >>A mon avis, ?a n'a de sens (et encore) que quand on a un tr?s grand > > >>nombre > > >>de CPUs, c?d une douzaine > > >>au minimum. Jusqu'? 8 CPUs le scheduler devrait faire un excellent boulot > > >>par lui-m?me (en tout cas > > >>pour le kernel 2.6 - pour 2.4, c'est sans doute un peu moins bon pour 8 > > >>que > > >>pour 4). > > >> > > >>- -- > > >>~ -o) Pascal Bleserhttp://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) > > >> > > >>iD8DBQFBmZd7r3NMWliFcXcRAvnhAJ9xiC4/6JstFP6AowHTVcJiC+RMtgCgrV56 > > >>bRXllixBVpOsP2gVnEaWfWk= > > >>=F96M > > >>-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 -- -- -> Jean-Francois Dive --> [EMAIL PROTECTED] I think that God in creating Man somewhat overestimated his ability. -- Oscar Wilde ___ 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
Re: [linux] CPU
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Silvestre wrote: | Au boulot nous avons aussi ce genre de grÃÃsse machine, mais à part des | disques et des ventilateurs et malgrà un dÃmÃnagement de quelques km et | une perte soudaine du courant dans toute la salle des serveur, nous | n'avons jamais rencontrà de problÃme hardware bloquant (aÃe, je ne | devrais pas dire Ãa). Pour info nous utilisons du materiel ibm pSeries. | Nous allons recevoir 2 nouveaux serveurs (p570) trÃs bientÃt. | Question maintenance et support, c'est vrai Ãa coÃte un pont. | | Petite question: avez-vous dÃjà eu de mauvaises expÃrience et avec quel | matÃriel ou quel fabriquant? Des anecdotes c'est toujours sympa. Nous (ou nos clients) n'avons pas vraiment eu de mauvaises expÃriences cÃtà stabilità ou mÃme performance, pour autant que je sache en tout cas. Moi c'est plutÃt l'aspect du coÃt que je voulais mettre en avant. Et en fait c'est assez simple à argumenter (en dÃfaveur des "grosses" machines): dans 99% des cas, tout le monde a un besoin en performances qui est assez stable sur toute l'annÃe. Il y a des peaks en journÃe, ou bien la nuit, mais grossomodo, c'est mesurÃ, bien connu et puis on sait acheter une machine (ou plusieurs) en fonction de cela. Je vais prendre l'exemple d'un de nos clients, VISA. Pour VISA comme dans la trÃs grande majorità des cas, il y a plusieurs pÃriodes de peaks trÃs forts sur l'annÃe, comme p.ex. noÃl, pÃques, la pÃriode de vacances. Pendant ces pÃriodes-lÃ, tu as un besoin en performance qui est souvent 2 à 3 fois supÃrieur à ton maximum sur l'annÃe. Tout ceci pour expliquer que si tu prends pour stratÃgie d'utiliser une (ou deux) trÃs grosse(s) machine(s) (disons une Sun Enterprise 15000), tu es forcÃment obligà d'acheter une machine grosse assez pour supporter la charge _maximale_ en production sur toute l'annÃe. Or, elle va s'emmr le reste du temps. Si, par contre, tu choisis une stratÃgie avec beaucoup (ou du moins plusieurs) machines plus "petites" (comme dÃjà dit, pas nÃcessairement des P3 avec 256MB RAM non plus hein ;)) que tu utilises en cluster, tu gagnes: 1) en redondance: lorsque des composantes matÃrielles rendent l'Ãme, une autre machine reprend la charge (oui, je sais, ces "grosses" machines ont quand mÃme pas mal de composants en redondance (alimentation, ...) mais bon, quand mÃme - essaye de couper une E15K en deux pour la mettre sur 2 sites ;)) 2) en coÃts: lorsque tu as ces pÃriodes "chaudes" sur l'annÃe, tu ajoutes des machines pour gÃrer la charge - mais ces machines peuvent Ãtre utilisÃes pour d'autres applications le reste de l'annÃe 3) en maintenance: oui et non: ~ - tu y perds à moins d'avoir des bons systÃmes de gestion de cluster (gÃrer 30 machines est à priori plus complexe qu'en gÃrer une seule, mÃme partitionnÃe) ~ - tu y gagnes parce que quand tu veux augmenter la performance, tu ajoutes qqes machines (p.ex. Intel ou AMD + Linux) - avec ton E15K, une fois la capacità maximale atteinte, il faudra en acheter une 2Ãme (et bonjour les frais) NÃanmoins, j'ajouterais un bÃmol à ce que Jef à dit: c'est beaucoup plus complexe d'implÃmenter une application qui fonctionne bien en termes de "scalability" (+/- "parallÃlisation") et de "failover" qu'une application qui fonctionne simplement avec beaucoup de CPUs. Donc Ãa dÃpend parfois aussi du cas de figure, du type et de la qualità de l'implÃmentation (software). Un cluster de serveurs web (p.ex. Apache ou Tomcat), Ãa se gÃre trÃs facilement en cluster de beaucoup de petites machines. Par contre, quand il y a beaucoup d'accÃs DB et beaucoup de donnÃes à ~ gÃrer, c'est dÃjà nettement plus compliquà (synchronisation des sessions, des caches, Ãviter la sÃrialisation des accÃs DB, XA est une horreur, ...). Enfin, Ãa fait vivre les architectes systÃme comme moi ;D Il faut aussi voir que tu dois investir dans un bon backbone en fibre optique (ou myrinet) pour relier les noeuds (machines) du cluster. En outre, le consommation en Ãlectricità est beaucoup plus importante pour 50 machines que pour 1 grosse - Ãa n'est gÃnÃralement pas pris en compte, mais si tu prends le cas de Google (1 machines AMD/Intel+Linux) ou dÃs que tu comptes plusieurs centaines de "petites" machines ... Il y a du pour et du contre, mais personellement, je suis à priori beaucoup plus pour une infrastructure de cluster de petites machines. Un avantage Ãnorme, c'est aussi que tu as des composants "standards", cÃd du hardware sur base Intel, AMD (ou mÃme PowerPC) que tu peux acheter chez plusieurs revendeurs (Intel, HP, Dell, Sun, et beaucoup d'autres). Avec les trÃs grosses machines, tu n'as pas tellement le choix (IBM z- et s-Series, IBM p-Series, Sun Enterprise). enfin voilÃ, my 0.02EUR ;) - -- ~ -o) Pascal Bleserhttp://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) iD8DBQFBn
Re: [linux] CPU
Au boulot nous avons aussi ce genre de grÃÃsse machine, mais à part des disques et des ventilateurs et malgrà un dÃmÃnagement de quelques km et une perte soudaine du courant dans toute la salle des serveur, nous n'avons jamais rencontrà de problÃme hardware bloquant (aÃe, je ne devrais pas dire Ãa). Pour info nous utilisons du materiel ibm pSeries. Nous allons recevoir 2 nouveaux serveurs (p570) trÃs bientÃt. Question maintenance et support, c'est vrai Ãa coÃte un pont. Petite question: avez-vous dÃjà eu de mauvaises expÃrience et avec quel matÃriel ou quel fabriquant? Des anecdotes c'est toujours sympa. -- Thomas Le mercredi 17 novembre 2004 à 10:31 +0100, Alain EMPAIN a Ãcrit : > > Jean-Francois Dive wrote: > > de toute facon les grosses caisses avec pleins de CPU c'est pas > > interessant, ca coute chers et ca crashe tout le temps. > > Un petit exemple ? > > Une machine 64 CPUs de 3 ans; pas possible de se passer du contrat de > maintenance car il est utilisà rÃguliÃrement... > > La valeur annuelle de ce contrat de maintenance Ãtait suffisante pour > acheter CHAQUE ANNEE plus de deux fois la puissance CPU, l'espace RAM, > l'espace HD sous forme de calculateurs dual-XEONS standards (32 bits), > facilement rÃparables, remplaÃables en cas de panne (ou additionnables > d'annÃe en annÃe) ou min une fois avec des Opterons (64 bits). > > Ok, pour interconnecter les noeuds à plus de 1Gb/s c'est plus cher mais > quand mÃme c'est bien plus souple, robuste et extensible comme solution ! > > A la limite, pas de contrat de maintenance : avec cet argent on achÃte > du nouveau matÃriel chaque annÃe (et on colle à la loi de Moore au lieu > d'entretenir un vieux trigu) et on peut mÃme se permettre de jeter > froidement ce qui ne va plus, sans y regarder ;-) > > Bonne journÃe, > > Alain > > > > Rien ne vaut un > > bon cluster de PC et ca dois marcher pour toutes les applications si > > elle est bien developee. > > > > On Tue, Nov 16, 2004 at 07:00:27AM +0100, Pascal Bleser wrote: > > > >>-BEGIN PGP SIGNED MESSAGE- > >>Hash: SHA1 > >> > >>Vincent Jamart wrote: > >>| 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. > >> > >>Oui, normal, SLES8 est sur kernel 2.4. > >> > >>A mon avis, ?a n'a de sens (et encore) que quand on a un tr?s grand nombre > >>de CPUs, c?d une douzaine > >>au minimum. Jusqu'? 8 CPUs le scheduler devrait faire un excellent boulot > >>par lui-m?me (en tout cas > >>pour le kernel 2.6 - pour 2.4, c'est sans doute un peu moins bon pour 8 que > >>pour 4). > >> > >>- -- > >>~ -o) Pascal Bleserhttp://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) > >> > >>iD8DBQFBmZd7r3NMWliFcXcRAvnhAJ9xiC4/6JstFP6AowHTVcJiC+RMtgCgrV56 > >>bRXllixBVpOsP2gVnEaWfWk= > >>=F96M > >>-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
Re: [linux] CPU
Fabian Vilers wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alain EMPAIN wrote: | A la limite, pas de contrat de maintenance : avec cet argent on achète | du nouveau matériel chaque année (et on colle à la loi de Moore au lieu | d'entretenir un vieux trigu) et on peut même se permettre de jeter | froidement ce qui ne va plus, sans y regarder ;-) Quelle indécence... :o) Tu penses bien que c'est mon genre... J'ai toujours un tournevis à deux lames sur moi ;-) Alain -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFBmyP/3Qzx239StfYRAi13AJ0cDHcaz6kVJI0dl07+qMmT6PFXAgCgnDLx ArjziWOBBBR/jgBjnJrGEFo= =EFLf -END PGP SIGNATURE- -- The information contained in this electronic message may be legally privileged and confidential under applicable law, and is intended only for the use of the individual or entity named above. If the recipient of this message is not the above-named intended recipient, you are hereby notified that any dissemination, copy or disclosure of this communication is strictly prohibited. If you have received this communication in error, please notify Keyware, +32 2 526 16 16 and purge the communication immediately without making any copy or distribution. ___ 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 -- Dr Alain EMPAIN <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Bioinformatics, Molecular Genetics, Fac. Med. Vet., University of Liège, Belgium Bd de Colonster, B43 B-4000 Liège (Sart-Tilman) WORK: +32 4 366 3821 FAX: +32 4 366 4122 HOME: rue des Martyrs,7 B- 4550 Nandrin +32 85 51 23 41 GSM: +32 497 70 17 64 --- [ Creative Commons ] Ne pas confondre 'Piraterie' et 'Partage des connaissances' : Faire circuler la connaissance est au coeur même de l'activité de création et d'invention. La connaissance scientifique est basée sur des siècles de partage créatif. 'Du bon usage de la piraterie' F. Latrive (PDF) http://www.freescape.eu.org/piraterie/complet.html --- ___ 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
Re: [linux] CPU
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alain EMPAIN wrote: | A la limite, pas de contrat de maintenance : avec cet argent on achète | du nouveau matériel chaque année (et on colle à la loi de Moore au lieu | d'entretenir un vieux trigu) et on peut même se permettre de jeter | froidement ce qui ne va plus, sans y regarder ;-) Quelle indécence... :o) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFBmyP/3Qzx239StfYRAi13AJ0cDHcaz6kVJI0dl07+qMmT6PFXAgCgnDLx ArjziWOBBBR/jgBjnJrGEFo= =EFLf -END PGP SIGNATURE- -- The information contained in this electronic message may be legally privileged and confidential under applicable law, and is intended only for the use of the individual or entity named above. If the recipient of this message is not the above-named intended recipient, you are hereby notified that any dissemination, copy or disclosure of this communication is strictly prohibited. If you have received this communication in error, please notify Keyware, +32 2 526 16 16 and purge the communication immediately without making any copy or distribution. ___ 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
Re: [linux] CPU
Jean-Francois Dive wrote: de toute facon les grosses caisses avec pleins de CPU c'est pas interessant, ca coute chers et ca crashe tout le temps. Un petit exemple ? Une machine 64 CPUs de 3 ans; pas possible de se passer du contrat de maintenance car il est utilisé régulièrement... La valeur annuelle de ce contrat de maintenance était suffisante pour acheter CHAQUE ANNEE plus de deux fois la puissance CPU, l'espace RAM, l'espace HD sous forme de calculateurs dual-XEONS standards (32 bits), facilement réparables, remplaçables en cas de panne (ou additionnables d'année en année) ou min une fois avec des Opterons (64 bits). Ok, pour interconnecter les noeuds à plus de 1Gb/s c'est plus cher mais quand même c'est bien plus souple, robuste et extensible comme solution ! A la limite, pas de contrat de maintenance : avec cet argent on achète du nouveau matériel chaque année (et on colle à la loi de Moore au lieu d'entretenir un vieux trigu) et on peut même se permettre de jeter froidement ce qui ne va plus, sans y regarder ;-) Bonne journée, Alain Rien ne vaut un bon cluster de PC et ca dois marcher pour toutes les applications si elle est bien developee. On Tue, Nov 16, 2004 at 07:00:27AM +0100, Pascal Bleser wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vincent Jamart wrote: | 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. Oui, normal, SLES8 est sur kernel 2.4. A mon avis, ?a n'a de sens (et encore) que quand on a un tr?s grand nombre de CPUs, c?d une douzaine au minimum. Jusqu'? 8 CPUs le scheduler devrait faire un excellent boulot par lui-m?me (en tout cas pour le kernel 2.6 - pour 2.4, c'est sans doute un peu moins bon pour 8 que pour 4). - -- ~ -o) Pascal Bleserhttp://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) iD8DBQFBmZd7r3NMWliFcXcRAvnhAJ9xiC4/6JstFP6AowHTVcJiC+RMtgCgrV56 bRXllixBVpOsP2gVnEaWfWk= =F96M -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 -- Dr Alain EMPAIN <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Bioinformatics, Molecular Genetics, Fac. Med. Vet., University of Liège, Belgium Bd de Colonster, B43 B-4000 Liège (Sart-Tilman) WORK: +32 4 366 3821 FAX: +32 4 366 4122 HOME: rue des Martyrs,7 B- 4550 Nandrin +32 85 51 23 41 GSM: +32 497 70 17 64 --- [ Creative Commons ] Ne pas confondre 'Piraterie' et 'Partage des connaissances' : Faire circuler la connaissance est au coeur même de l'activité de création et d'invention. La connaissance scientifique est basée sur des siècles de partage créatif. 'Du bon usage de la piraterie' F. Latrive (PDF) http://www.freescape.eu.org/piraterie/complet.html --- ___ 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
Re: [linux] CPU
de toute facon les grosses caisses avec pleins de CPU c'est pas interessant, ca coute chers et ca crashe tout le temps. Rien ne vaut un bon cluster de PC et ca dois marcher pour toutes les applications si elle est bien developee. On Tue, Nov 16, 2004 at 07:00:27AM +0100, Pascal Bleser wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Vincent Jamart wrote: > | 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. > > Oui, normal, SLES8 est sur kernel 2.4. > > A mon avis, ?a n'a de sens (et encore) que quand on a un tr?s grand nombre > de CPUs, c?d une douzaine > au minimum. Jusqu'? 8 CPUs le scheduler devrait faire un excellent boulot > par lui-m?me (en tout cas > pour le kernel 2.6 - pour 2.4, c'est sans doute un peu moins bon pour 8 que > pour 4). > > - -- > ~ -o) Pascal Bleserhttp://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) > > iD8DBQFBmZd7r3NMWliFcXcRAvnhAJ9xiC4/6JstFP6AowHTVcJiC+RMtgCgrV56 > bRXllixBVpOsP2gVnEaWfWk= > =F96M > -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 -- -- -> Jean-Francois Dive --> [EMAIL PROTECTED] I think that God in creating Man somewhat overestimated his ability. -- Oscar Wilde ___ 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
Re: [linux] CPU
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pascal Bleser wrote: | A mon avis, ça n'a de sens (et encore) que quand on a un très grand | nombre de CPUs, càd une douzaine | au minimum. Jusqu'à 8 CPUs le scheduler devrait faire un excellent | boulot par lui-même (en tout cas | pour le kernel 2.6 - pour 2.4, c'est sans doute un peu moins bon pour 8 | que pour 4). En tout cas, merci à tous pour ces interventions sur ce thread. Bien à vous, Fabian -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFBmbcv3Qzx239StfYRAtbnAJ4wSlADb9Dct2UCAGuCG8xkSVfobACeIBlT 6RPHQLkrfARbsM0UxKh74i0= =Wmmf -END PGP SIGNATURE- -- The information contained in this electronic message may be legally privileged and confidential under applicable law, and is intended only for the use of the individual or entity named above. If the recipient of this message is not the above-named intended recipient, you are hereby notified that any dissemination, copy or disclosure of this communication is strictly prohibited. If you have received this communication in error, please notify Keyware, +32 2 346 25 23 and purge the communication immediately without making any copy or distribution. ___ 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
Re: [linux] CPU
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vincent Jamart wrote: | 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. Oui, normal, SLES8 est sur kernel 2.4. A mon avis, ça n'a de sens (et encore) que quand on a un très grand nombre de CPUs, càd une douzaine au minimum. Jusqu'à 8 CPUs le scheduler devrait faire un excellent boulot par lui-même (en tout cas pour le kernel 2.6 - pour 2.4, c'est sans doute un peu moins bon pour 8 que pour 4). - -- ~ -o) Pascal Bleserhttp://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) iD8DBQFBmZd7r3NMWliFcXcRAvnhAJ9xiC4/6JstFP6AowHTVcJiC+RMtgCgrV56 bRXllixBVpOsP2gVnEaWfWk= =F96M -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
Re: [linux] CPU
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 Bleserhttp://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
Re: [linux] CPU
-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 Bleserhttp://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
Re: [linux] CPU
j'avais lu ce genre de chose dans les commentaires relatifs au kernel 2.6. Cela a par ex. de l'intérêt dans un dual-XEON qui fait de l'hyperthreading : il est vu comme 4 CPUs mais certains sont moins égaux que d'autres... Bon week-end, Alain Fabian Vilers wrote: BOnjour à tous, 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. Merci pour vos réponses! Bon week-end, Fabian -- Dr Alain EMPAIN <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Bioinformatics, Molecular Genetics, Fac. Med. Vet., University of Liège, Belgium Bd de Colonster, B43 B-4000 Liège (Sart-Tilman) WORK: +32 4 366 3821 FAX: +32 4 366 4122 HOME: rue des Martyrs,7 B- 4550 Nandrin +32 85 51 23 41 GSM: +32 497 70 17 64 --- [ Creative Commons ] Ne pas confondre 'Piraterie' et 'Partage des connaissances' : Faire circuler la connaissance est au coeur même de l'activité de création et d'invention. La connaissance scientifique est basée sur des siècles de partage créatif. 'Du bon usage de la piraterie' F. Latrive (PDF) http://www.freescape.eu.org/piraterie/complet.html --- ___ 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] CPU
BOnjour à tous, 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. Merci pour vos réponses! Bon week-end, Fabian -- Fabian Vilers http://www.vilers.net/~fabian ___ 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
Re: [linux] CPU AMD
On Thu, 16 May 2002 08:24:36 +0200 Fabian Vilers <[EMAIL PROTECTED]> wrote: > Habitué des CPU d'Intel, je projette d'acheter un nouveau CPU mais AMD cette > fois-ci. Avant de me décider totalement, je me demandais s'il y avait des > problèmes de compatibilé avec ces CPU et Linux (je suppose que non, mais > préfère me renseigner). > > Merci pour votre feedback > > [oT] > Que me conseillez-vous comme motherboard pour ce CPU...? Moi j'ai une Epox EP-8KHAL +256Mo DDR Pour la config du module sonore ac97 :o( Je ne te la recommande pas pour un serveur. Si la charge monte de trop, j'ai un plantage du bus. Je ne sais pas trop à quoi c'est dû mais à défaut de preuve que ce n'est pas une mauvais config de ma part J'ai fait le radin et voilà.:o( Benoît
RE: [linux] CPU AMD
Title: RE: [linux] CPU AMD merci a tous pour les infos, faut encore prendre la décision now! > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: jeudi 16 mai 2002 09:44 > To: [EMAIL PROTECTED] > Subject: Re: [linux] CPU AMD > > > Fabian Vilers <[EMAIL PROTECTED]> writes: > > > Habitué des CPU d'Intel, je projette d'acheter un nouveau > CPU mais AMD cette > > fois-ci. Avant de me décider totalement, je me demandais > s'il y avait des > > problèmes de compatibilé avec ces CPU et Linux (je suppose > que non, mais > > préfère me renseigner). > > J'ai un athlon première génération sans aucun problème. Il semblerait > qu'il y a quand-même eu des problèmes de plantages avec certains > chipsets, mais que le problème est résolu maintenant moyennant le > passage d'un paramètre au kernel. > (voir http://slashdot.org/articles/02/01/21/0750226.shtml) > > -- > Rémi > > `Debian: giving you the power to shoot yourself in each > toe individually.' -- with kudos to Greg Lehey > ___ > Linux Mailing List > LCP - 11 Mai - http://www.unixtech.be/lcp.php > Archives: http://www.unixtech.be/mailman/listinfo/linux >
