Reprise du message précédent :

essayes d'espacer ou de mettre éventuellement en quote les exemples  
(le #/dev/sda...) afin que ce soit plus lisible.

pas évident, genre ça ?

voila c'est l'idée.

concernant le 2.6.29 et l'intel ATOM il y aurait dans la rc8 un début de correction : http://lkml.org/lkml/2009/3/13/8

Je viens de faire un peu joujou avec Powertop sur mon Acer Aspire One, quelques résultats en vrac :

-consommation minimale (Wi-Fi coupé, session XFCE ouverte mais aucun soft qui tourne, aucun périph USB, rétroéclairage mini, usb autosuspend) : 7,5W
-idem mais avec Wi-Fi activé (connecté à mon AP, mais idle) : 8,0W
-utilisation web (typiquement en ce moment même en train de taper ce texte : rétroéclairage au minimum, Firefox 3 ouvert, Wi-Fi activé, rien d'autre qui tourne) : 9,1W
-idem mais écran rétroéclairé au maximum : 10,4W

À titre indicatif, le branchement d'une Logitech Optical USB coûte à peu près 0,4W.

Ah oui, quelques précisions :
Arch Linux et kernel 2.6.28

ici avec le rétroéclairage a fond et un firefox un peu plus avec un 11W avec kde4 et un 2.6.27 sur une mandriva 2009.0
Il est je pense plus utile de réaliser ce genre de tests en activité de tous les jours
 
(bon ok, c'est vrai que dans la première hypothèse que tu as décrite je tourne encore a 8W)

Ca change vraiment quelque chose le scheduler ?

chez moi l'Apire one (la version 110 ) est sensiblement plus véloce avec l'utilisation de noop ou de deadline par rapport a cfq.

quid de BFQ?

un lien intérressant  
http://forum.eeeuser.com/viewtopic.php?id=62003

pour l'autosuspend usb il suffit de rajouter usbcore.autosuspend=1 au niveau du lancement du kernel.
(lancer powertop en ssh sur un plus grand écran permet de voir *tout* les commentaires )

là epithète (thread LKML) ?
http://www.gossamer-threads.com/li [...] el/1027569

le lien ne  fonctionne pas.

ah oui, tiens, corrigé

 
Pour ma part je confirme ce qui est dit dans le thread : sur le même matos (AAO), noop provoque de plus long freezes lors de l'accès au SSD que CFQ.

C'est bien ce que j'avais remarqué
 
Je remets donc le scheduler par défaut !

en ce qui me concerne j'ai opté pour deadline.

1 suggestion et 1 question :
 
- suggestion : pour le syslog, pourquoi ne pas monter en tmpfs  /var/log (comme ça a été dit), ET faire un cron, ou écrire dans le rc.shutdown pour le sauvegarder en dur ? (dans un rep /var/log2 par exemple)
 
- question : qui peut m'expliquer à quoi sert l'autosuspend de l'usb ? Merci !  

 
l'auto suspend sert à ne pas faire poller le port USB pour vérifier si un device est branché

ok, merci pour l'info.

Bon, retour sur deadline, et effectivement, ça transfigure le netbook  

Je ne m'en étais pas rendu compte quand j'avais essayé avant (et mon problème de log me l'avait fait désactiver), mais là avec deadline, syslog désactivé, /tmp en tmpfs, c'est vraiment excellent  

je me demande si je ne vais pas le faire pour tous mes PC... une contre-indication peut-être ? (là, tout de suite, je n'en vois aucune)

Tout dépend de l'utilisation de tes PC :
 
http://fr.wikipedia.org/wiki/Deadline_scheduler
http://fr.wikipedia.org/wiki/Completely_Fair_Queuing
http://fr.wikipedia.org/wiki/Noop_scheduler
http://fr.wikipedia.org/wiki/Anticipatory_scheduling

ok, merci, il faut donc tester et juger...

j'ai mis à jour la 1re page pour signaler l'option noop/deadline

J'ai fait un tmpfs sur mon portable avec disque dur 5200rpm et 4Go de RAM, j'ai aussi déporté le cache de firefox dessus, et augmenté l'intervale de commit de ext4.  
En réactivité, le gain est sensible à mon avis mais le disque est toujours réveillé régulièrement (sauvegarde de l'historique de firefox apparemment) et ça empêche un parcage des têtes efficace, donc j'ai remis un iddle time du disque dur plus laxiste avec laptop-mode.
Le but était surtout de gagner en autonomie sur batterie.
Par contre, j'ai pas envie de me prendre la tête avec des scripts de sauvegardes des répertoires en tmpfs...

Avec un disque lent en écriture, Firefox est clairement une calamité.
 
Sur l'Acer AO, j'utilise Epiphany, et j'ai hâte que Midori devienne stable.

il l'est chez moi

Quelle version ?
 
Tu as flash d'installé ?
(j'ai l'impression que c'est ça qui le fait planter en fait)

Je n'ai pas encore mesuré le gain du cache de firefox, je l'ai fait très récemment (avant-hier). Toujours est-il qu'un df m'indique que ça ne prend que qq Mo, je m'attendais à bien plus...

on sort un peu du sujet, mais en browser léger, il y a aussi kazehakaze et dillo...
EDIT : le pb, c'est qu'on s'habitue trop vite aux extensions de firefox !

flash peut le rendre instable
tester avec flash et swfdec
je suis sous Ubuntu et j'utilise les dépôts de Stemp

Bon, solution simple et efficace adoptée pour FF : profil sur un ramdisk.
 
Ça marche vraiment super bien, une requête dans la Awesome Bar devient instantanée, ça rame vraiment plus du tout, super agréable.
 
Donc aujourd'hui, je me fais le script pour créer le ramdisk à l'ouverture de session et le synchroniser avec le profil stocké sur le disque, et inversement à l'extinction.

Excellente idée !
Pourrais-tu partager tes scripts, STP ?
J'ai bien qq idées, mais elles ne me satisfont pas entièrement...  

quelques liens que je soumets à votre sagacité (How to make ext3 or reiserfs use journal data writeback, - tune2fs, CONCURRENCY=shell, Readahead)
http://www.ubuntugeek.com/how-to-i [...] mance.html
http://tuxtraining.com/2008/09/28/ [...] emely-fast
http://tuxtraining.com/2008/09/08/ [...] in-ubuntu/
 

Alors j'ai fait simple :

-Une ligne dans /etc/fstab

-Une ligne dans /etc/rc.local pour effectuer au démarrage la synchro du répertoire de référence situé sur le SSD, vers le répertoire en ram (qui à ce moment là est vide) :

-La même chose dans l'autre sens dans /etc/rc.local.shutdown, afin de synchroniser du répertoire en ram vers le répertoire de référence sur le SSD, pour que tout soit gardé au prochain démarrage de la machine :

Simple et efficace.
Ce qui est bien, c'est que même un crash brutal ne foirera pas le profil, on reviendra simplement à la version du boot précédent.
Evidemment, au niveau des scripts de démarrage/extinction c'est à adapter suivant la distribution, là ça vaut pour Arch Linux.

Edit : bien sûr, il faut d'abord :
-renommer ton ancien ~/.mozilla en ~/.mozilla_ref
-créer un nouveau ~/.mozilla

Merci deK, je pensais bien à cette solution (rsync, rc.local et rc.shutdown)... là où je me trompais, c'est en cas de veille ou hibernation, je pensais que l'on perdait tout (à tort, je ne sais pas où étaient mes neurones tout à l'heure ! ).
 
NB : je tourne aussi sur Arch ! (on s'est même croisés dans d'autres topics à propos de notre distrib)  

tu peux aussi simplement copier le .mozilla d'origine en .mozilla-ref.
cela permettra au pire d'avoir toujours l'original  

que "se passe-t-il" si on monte en tmpfs un répertoire initialement non vide ?

L'ancien contenu n'est plus accessible (tant que le nouveau montage est présent) mais toujours présent sur le media d'origine, enfin il me semble.
 
Toujours est-il que cette astuce transfigure complètement FF sur l'AAO  

Pour FF, de mon coté, je n'ai utiliser le tmpfs que pour le répertoire du cache (sans sauvegarde ni restauration)? Quel intérêt(s) y a t'il à le faire pour tout le répertoire ? (surtout que ça oblige à faire une sauvegarde / restauration)