Reprise du message précédent :

 
histoire perso : depuis 2 ans, j'ai 2 go de ram en gentoo, et plus de swap. J'ai du avoir droit à 5 ou 6 cas où la machine est arrivée à bout de souffle - plus de ram - et ou ma kernaille a killé le vilain process qui bouffait tout.  
 

Bah il est certain que le principal besoin de puissance/RAM chez le particulier vient des jeux vidéo. Avec les PC actuels, on se retrouve vite avec une machine largement sous exploitée sous linux. Si en plus tu ne touches pas aux VM, faut déjà s'accrocher pour tuer ne fût-ce que 1Go de RAM (avec autre chose que du cache/buffer, je veux dire).

j'ai réussi hier soir
1.6 Go de RAM active dans la gueule

Pas besoin de 9500 onglets pour que FF bouffe autant

non mais j'ai essayé involontairement d'en ouvrir 9500, stoo

 
Je confirme. Suffit de tomber sur une belle fuite mémoire et boom "oh tiens, firefox bouffe 3Go de RAM, je me disais bien que la machine se traîne".
Ca m'est arrivé quelques fois avec les premières versions de la 3.0.

 
à une époque le topic des gifs ça marchait pas mal. Il s'en sort un peu mieux maintenant

mmm 2.6.29-2 in progress

T'as 3 jours de retard

Un article intéressant : Solving the ext3 latency problem (flagrant quand on vient de Reiser v3 comme moi, d'ailleurs, j'hésite à passer le cap ext4).

Justement, je lisais ceci ce matin : http://www.phoronix.com/scan.php?p [...] arks&num=1
 
Je lirais le tien de suite si je devais pas aller bosser.

C'est vrai que c'est interressant. J'avais lu cet article il y a quelques semaines ainsi que le topic Optimisation du fonctionnement d'un Netbook et alors j'ai compiler un 2.6.30.
 
Après divers essais, le mode data=writeback améliore les perfs en écriture avec un 2.6.29. Avec un 2.6.30, les perfs avec un data en ordered ou writeback est quasi identique.  
 
En fait, on peut toujours utiliser ces astuces tel le mode de journalisation (data=) et/ou l'ordonnanceur (ex. elevator=deadline) pour améliorer les perfs mais à partir du 2.6.30, elles auront moins d'effet. Ce noyau intégrera beaucoup d'améliorations.

ogaby> en l'occurrence, tu parles d'ext3 ou 4 ?

en ext3...
 
J'avais fais la comparaison entre les 2 noyaux (29 et 30-rc6) avec du ext3, il y a 2 semaines et entre temps je suis passé en ext4. Pour moi, le noyau apporte beaucoup.

Tu me fais penser que je devrais peut-être repasser en cfq. J'étais passé en deadline autour du 2.6.27 dans l'espoir minimiser les freezes ext3 mais ce n'est peut-être plus nécessaire. Depuis j'ai migré vers ext4 sur un noyau vanilla toujours à la dernière stable ou RC dés qu'elles dépassent la version 6.
Non pas que deadline me cause des soucis, mais je me dis que cfq étant l'ordonnanceur par défaut, il a des chances d'être mieux maintenu/plus largement testé.
Là j'ai passé barrier=0 sur mes partitions ext4 mais pas encore testé le résultat. Ce sera pour ce soir.

2.6.30 dispo

Zut je voulais être le 1er à l'annoncer.
 
D'habitude ils sortent le noyo le vendredi soir comme ça, on a le temps de le compiler le Week-End. Bon là c'est férié.

gourage de topic  

le topic uname c'est à coté
 
Mise à jour du titre du topic \o/

boulay, désolé ^^

 
Après l'avoir utilisé qq jours, la différence est flagrante en écritures multiples. Par exemple, lors de l'extraction de sources depuis une grosse archive ou encore la mise à jour de multiples packages, ça va deux à trois fois plus vite lors des phases d'écriture.
Le fait que j'utilise encore des disques PATA sans NCQ amplifie sans doute la différence.

J'ai essayé et effectivement j'ai remarqué le changement.
 
J'ai voulu faire des tests avec différents paramètres comme data=writeback, noatime, etc... puis de lancer des benchmarks pour quantifier. Jusqu'ici je suis pas arriver à bien paramétrer les benchmarks car à chaque fois les perfs sont quasi pareil.
 
Là je viens à l'instant de trouver un article sur les perfs en disant les paramètres. ext4 File System: Introduction and Benchmarks

Donc le test est avec iozone et la commande est: iozone –s 2g –r 16384 –i0 –i1 /dev/<disk> ( ou plus simplement iozone –s 2g –r 16m –i0 –i1  )
Ses résultats:

Ce soir, je ferais des tests à la maison avec différents paramètres et avec le noyau 2.6.29 et 2.6.30. Comme je l'a dit précédemment le "30" comporte beaucoup d'optimisations des disques.
 
Je pense aussi qu'il sera intéressant de faire un topic dédié aux système de fichiers et ses optimisations possibles.

je vote pour vu que je suis passe a ext4 il y a peu

J'ai eu un fsck ce matin (tous les 15 jours, donc habituel), et je n'ai pas vu de "processus asynchrone" lors du montage/vérification des disques. Faut-il modifier quelque chose ?

 
 
Faut attendre une amélioration si on utilise ReiserFS (+lvm+crypté mais jpense pas que ça joue) ?

je me suis trompé: l'optimisation n'est pas sur les disques mais sur ext3 et ext4. Voir l'ensemble des nouveautés ici: http://linuxfr.org/2009/06/10/25555.html

 
Et ca: http://git.kernel.org/?p=linux/ker [...] 7bf6de47bc
 
En gros il suffit de rajouter le paramètre fastboot (dans son /boot/grub/menu.lst ?) ?
Cela marche t-il avec des partitions non ext4 ou est-ce aussi un pré-requis ?

fastboot est un nouveau paramètre qu'on peut rajouter dans grub. Exemple:

Il est indépendant du système de fichier. Cette option permet au noyo de démarrer (tout au début) en parallèle des processus si c'est possible.
J'ai essayé pendant environ 2 semaines (en RC) et je n'ai remarqué aucune différence dans les performances... ni régression d'ailleurs.
 
Chacun peut essayer: un simple copier/coller dans grub. Peut-être que certain remarqueront une amélioration.

J'ai cru comprendre que ca permettait de monter plus tôt le root, et de ne pas "geler" le temps de boot lors de scan de plusieurs disques.
 
J'ai dû mal comprendre, je vise peut être trop loin en imaginant le scan de plusieurs disques en même temps.

rien changé ici aussi

d'un autre côté, ça accélère le démarrage du noyau proprement dit, pas le truc qui prend le plus de temps sur une machine grand public

non, moi c'est Udev Events machins, ça bloque tout pendant au moins 3/4 secondes

Le 2.6.31-rc8 ne démarre pas sur ma machine.  Il ne fait plus rien peu après "loading hardware drivers [OK]". Pas de message d'erreur, aucune trace dans les logs. Je peux changer de tty ou encore rebooter proprement avec ctrl-alt-del mais rien de plus.
Je sais que le code coupable est arrivé dans le rc7-git6. Il y en a peu, mais ils sont assez obscures. Parmi lesquels les commits pour 9p, powerpc et xenfb ne me concernent pas. Ca laisse 8-9 coupables potentiels, mais j'ai aucune idée de comment réduire la liste.  

je viens de voir cela passer sur irc pour le kernel de mandriva (l'heure est bien sur locale)

je recherche le patch sur le svn pour toi.
 
edit : voila : http://svn.mandriva.com/cgi-bin/vi [...] iew=markup

Ca me rassure. Il s'agit bien d'une régression et non d'une nouvelle gestion qui laisserait sur le carreau les machines avec un bios bugé, ou autre (avec une asus basée sur nforce, il y a toujours matière à s'inquièter ).
Je vais attendre la rc8-git1 qui, avec un peu de chance intégrera ce correctif, sinon je patcherai moi-même.
 
Merci

Dites les gens, l'update du kernaïl en 2.6.30-5, normal...
Mais, le uname qui me sort un 2.6.30-1, c'est pas trop normal si ?
Synaptic m'annonce fièrement 2.6.30-1 version 2.6.30-5...

Pas normal. Avec les sources vanilla, la version est correcte. La version vanilla, c'est 2.6.30.5, pas 2.6.30-5 donc déjà, on voit qu'il s'agit d'une numérotation de distrib. Comme tu parles de synaptic, ça doit être debian. Sans doute que le packager s'est planté dans son changelog ou en éditant le Makefile.

Sous debian, c'est bien comme ça. Le noyau s'appelle toujours 2.6.X-1 (voire 2.6.X-2 mais c'est rare). Seule la version de vanilla est indiquée à titre informatif dans le paquet.

Oui, pardon, je me croyait sur barbus XD
Donc, oui, s't'un débian testing...
Apt-cache show linux-image-2.6.30-1-amd64 m'indique :
Package: linux-image-2.6.30-1-amd64
[...]
Architecture: amd64
Source: linux-2.6
Version: 2.6.30-6
[...]
WTF oO ?
(oui, j'ai des dépots testing et unstable, sa aide pas, mais normalement, c'est pinné correctement...)
EDIT : merci ogaby, mais le comportement de uname est normal ? pour rappel, j'ai uname qui me dit fièrement 2.6.30-1...

Disons que tu peux faire dire n'importe quoi à uname. Suffit d'éditer "extraversion" dans le Makefile. Ensuite le nom du package et son descriptif vu par synaptic dépendent de debian/changelog et du paramètre --append-to-version.

Le -1 dans le nom du paquet c'est une version d'ABI (pour gérer correctement les dépendances avec les modules par exemple je crois), le -6 dans le numéro de version debian c'est juste la 6ème release debian, dans les deux cas ca n'a rien à voir avec le vanilla 2.6.30.1 ou 2.6.30.6.

Pour savoir quelle version mineure du 2.6.30 est dans le kernel debian, faut lire le changelog :