Reprise du message précédent :

Nième sortie de Linus ?
Dev’ *BSD qui se moque du foutoir dans la kernouille ?

http://linuxfr.org/2010/05/17/26852.html#squashfs
http://article.gmane.org/gmane.linux.kernel/957295

Vous avez vu ce bench ?
 
Five Years Of Linux Kernel Benchmarks: 2.6.12 Through 2.6.37
http://www.phoronix.com/scan.php?p [...] 2637&num=1
 
Je m'attendais à des évolutions plus visibles en moyenne, bien qu'il y ait des bonds/régressions spectaculaires.

A good news for linux 2.6.38 : http://www.phoronix.com/scan.php?p [...] ideo&num=1

Je ne crâche pas sur les améliorations, mais j'ai jamais constaté de ralentissements en compilation
C'est un peu extrême leur test de compil avec 64 jobs, ca vaut quoi sur une compil avec 2/4 jobs ?

Je compile généralement en multipliant par 1.5x ou 2x le nombre de cores pour obtenir le nombre de job. Quand ça compile, il m'arrive de voir ma machine incapable d'accéder aux hdd pendant plusieurs dizaines de secondes. Les appli déjà chargées réagissent sans ramer (je peux lire une vidéo HD sans problème, par exemple). Pour moi, c'est surtout sur l'i/o scheduler qu'il faudrait bosser au lieu du cpu scheduler.
 
Je vais quand même repasser en CFS (BFS actuellement) et tenter le coup avec l'autogroup. J'y crois pas trop, cela dit.

L'avis d'un développeur Gentoo : http://www.phoronix.com/forums/sho [...] stcount=10

Apparement le 2.6.36 (Sous Arch) me pete le wifi atheros (5008)
J'ai des desynchros ttes les 10mn env, avec un log dmsg a propos d'un timeout
Un autre pc avec le meme kernel, même os, même Ap mais un chip ralink ne semble pas affecté.
Je downgrade, reboot et reteste

Auto réponse: http://gnu-vautes.eg2.fr/un-petit- [...] t-le-buzz/

 
Le gars balance 20 jobs sur un monocore. A croire que personne n'est capable d'imaginer un use case réaliste pour ce patch

il faut surtout garder à l'idée que c'est lié à tty et au support cgroup.

Il balance 20 jobs car il faut faire monter en charge le processeur pour voir ou ressentir la différence.
 
On peut imaginer un autre cas plus simple. Genre on écoute de la musique et on regarde une vidéo sur youtube. Là il y a le lecteur de musique, le navigateur, flash et tous les processus en arrière plan. Ben ça ne doit pas peser de problèmes pour tout le monde (sauf peut-être de vieilles machines). Et avec ce patch, ça en poserait encore moins.
 
Ce que j'ai compris de ce test et des commentaires dans phoronix, pour une utilisation normale, on ne ressent pas l'avantage du patch.  
 
(et on peut attendre le 2.6.38 sans être frustré )
 

Bon, rendons à César ce qui est à César, sur mon quad ça fait quand même une différence avec 6 jobs. Les effets visuels de KDE sont aussi réactifs en charge qu'en idle, là où avant, ils ramaient légèrement. C'est pas la révolution, mais le ressenti est plus agréable.
Dés que j'ai le temps, je vais ajouter un encodage h264 sur 6 threads et une grosse copie de fichier aux 6 threads de la compil.

 
J'ai mis 20 jobs à la compilation parce qu'à 10 on voit à peine la différence, le système ram un peu, mais pas trop quand même ... Donc pour être sûr que l'amélioration n'est pas juste dans la tête j'y suis allé violent. C'est pas évident de donner une impression quand tu sait que t'as changé un gros truc, tu te dit que tout va aller mieux, et que finalement même si ça va pas mieux tu sent que ça va mieux.
 
Donc au final, après une journée d'utilisation normal de mon système, je sais même pas si j'ai gagné quelque chose, peut être quelques légers blocage de scroll dans Firefox en moins. J'ai pas fait monté mon système en charge non plus, mais de toute façon dans une utilisation normal mon système rammait déjà assez peu ... En gros j'ai plus à mettre nice devant mes grosses commandes, et quand le flash à décidé de prendre 100% du CPU Firefox reste fluide. Enfin voilà en gros j'ai l'impression d'avoir un dual core à la place d'un simple mono cœur en terme de réactivité, mais donc c'est pas flagrant comme différence.
 
Sinon aussi j'ai l'impression que le load average du système a pas mal augmenté à la suite de l'application du patch, donc les grosses tâches doivent prendre plus de temps à s'exécuter

http://www.webupd8.org/2010/11/alt [...] patch.html
Comme quoi on peut éviter l'étape compilation en configurant simplement son bashrc...

Dans 3 jours il suffira de passer la poussière sur son pc pour que ça marche

Commentaire de Con:
http://ck-hack.blogspot.com/2010/1 [...] mment.html

 
J'ai fais la manip pour Ubuntu n'ayant pas de dossier cpu dans /sys/fs ... pas vraiment testé mais ça joue que si on a une grosse tache dans le terminal non? Puis vu la puissance de mon netbook je risque pas de pouvoir lire une video HD quoi qu'il arrive

le patch lui même ne joue que pour ce qui est attaché aux tty de toute manière.
Une fois que l'on a compris la limitation de la chose, les conditions pour que ce soit utile, on se rend compte que ce n'est pas une vraie révolution.

bon ben moi j'ai rien compris au final

en résumé, ce n'est pas une révolution.
Tu le verras *peut être* mais c'est pas sur dans le 2.6.38 en gardant à l'idée que Con est contre, que l'on propose la même solution sans mettre un truc gruik dans le kernel etc etc

Merci c'est beaucoup plus clair  

« Ceci, est une révolution. Le i-Patch kernel. »

Il a bien présenté le multi tâches comme une révolution sur l'iOS (enfin multi tâches...)

On se fout de lui mais ça fait des années qu'il fourgue sa camelote à prix d'or grâce à ce genre de pirouettes.

 
Je suis pas sûr que c'est de lui qu'on se fout, donc

2.6.37 dans la nature: http://linuxfr.org/2011/01/05/27723.html

Yep j'ai lu ça ce matin. Beau boulot

 
 
Va falloir chauffer le make  

Les noyaux longterm sont différents des stables ?
 
Le 2.6.35.10 est sorti en longterm mais pas en stable. Y a une raison que qq'un connaît ?
 
Si c'est parce que la "branche" stable est figée pour la série 2.6.35, et donc obsolète, pourquoi la faire apparaître sur la page d'accueil de kernel.org ?
 
Et au passage, comment on en est arrivé à avoir 3 "séries" longterm très proches : 2.6.32, 2.6.34 et 2.6.35 ?

longterm, c'est juste qu'un ou plusieurs dev ont décidé de prendre cette version pour base et de la maintenir à long terme, typiquement dans les distributions entreprises comme RH, Suse etc, dans le cas du 2.6.35, me semble que c'est pour l'embarqué.

La branche stable, c'est juste les correctifs de la version n quand la n+1 est en dev.

2.6.38 out .
-> http://linuxfr.org/news/le-noyau-l [...] rsion-2638

Petite question sur le paragraphe "Trusted keys":

Donc si on a du matos qui rend l'âme, ou que l'on change délibérément une pièce, réinstallation obligatoire car clefs incorrectes ?

euh, c'est une fonction activable à la config. d'installation, je pense, non?