bonjour,
est-il possible (cela existe-t-il ou non ?) d'éteindre son portable (ou sa machine) avec un suspend to disk ?
En gros lorsque j'éteins ma machine, toute la mémoire se copie sur le disk, la swap reste inchangée, rien ne se modifie)
Lorsque je rallume, toute cette 'partition' se recolle en ram et la vie est belle.(5 secondes ?)
est-ce possible ?
est-ce idiot ? (initialisation périphériques/ autres ?)
est-ce souhaitable ?
Cela gagnerait pas mal de temps au démarrage non ? avec une option éteindre profondément ou on aurait un vrai SHUTDOWN. On grillerait les win au démarrage non ?
# ca existe sous Win
Posté par Damien Metzler . Évalué à 2.
Sous Linux, je crois que ça fait appel à l'ACPI qui est plus ou moins bien implémenté sur les différentes machines.... du coup des fois ça marche, des fois ça marche pas (comme dans mon cas).
Bon sinon sous Windows, au bout d'un certain moment faut quand même rebooter a cause des leak des différents soft qui te font consommer plein de ram (j'ai pas dis firefox !!!)
Enfin voilà, ya pas besoin de réinventer l'eau chaude quoi ....
[^] # Re: ca existe sous Win
Posté par neil . Évalué à 2.
Le kernel ne récupère pas la mémoire lorsque le prog se termine ?
# oui et non
Posté par Jack DeNoumea (site web personnel) . Évalué à 2.
quelques patch noyau un conf de lilo/grub et voila
par contre c'est pas tre simple à mettre en oeuvre je trouve, faut bien virer les drivers spéciaux style ndiswrapper/video
Pour la vitesse, ça dépend de ton disque et de ton controleur, sur mon portable j'ai pas des acces rapides et j'ai pas de différences entre un démarrage normal et celui avec le rechargement depuis la swap vu qu'il doit charger tout ce qui est en ram...
[^] # Re: oui et non
Posté par tipote . Évalué à 3.
De mon côté, je l'utilise depuis plusieurs mois avec succès, et maintenant je trouve ça indispensable. Effectivement, un patch du noyau, une ligne de conf pour le bootloader, et en plus le script "hibernate" de http://www.suspend2.net(...) suffisent.
Concernant les drivers, ce n'est plus si terrible que ça a été : il y a un an encore, impossible de suspendre avec un seveur X lancé. Dorénavant, je n'ai rien de particulier à faire.
Les modules usb représentent apparemment le plus gros problème actuel pour la suspension, à cause des débranchements éventuels quand la machine est éteinte. Le script en question les décharge à la suspension et les recharge au réallumage. Je n'ai pas de soucis avec les autres pilotes sur mon portable (touchpad, carte graphique, carte son, etc , dans un compaq presario p4m). J'ajouterai que l'implémentation de http://www.suspend2.net(...) ne dépend pas de l'acpi (pas plus que celle de windows je crois). Ce n'est donc pas un souci, d'autant plus que les dernières versions des noyaux fournissent un support assez satisfaisant de l'acpi.
Ensuite, en ce qui concerne la vitesse, je trouve le gain considérable. C'est vrai que linux a tendance à utliser la ram à fond dès qu'on utilise la machine depuis un bon moment. Chez moi, c'est une image de 500 mo (pour 768mo de ram) en moyenne qui est écrite à la suspension puis lue au démarrage (contrairement à windows qui occupe plutôt de l'ordre de 200 mo, fuites exceptées). Sachant que le disque de mon portable fait du 20 mo/sec, ça fait une trentaine de secondes pour la suspension et autant pour la reprise. Même si on est loin des 5 secondes, c'est toujours beaucoup plus rapide qu'un démarrage à froid, qui se compte en minutes,en comptant le démarrage ultérieur des applications...
En fait, c'est particulièrement confortable à l'usage. On profite en effet de toutes les mises en cache précédentes et les applications réagissent ou se lancent de manière très réactive.
Pour finir, je ne saurais que conseiller aux motivés de se lancer, c'est vraiment pratique.
[^] # Re: oui et non
Posté par tgl . Évalué à 3.
Ouais, je suis bien d'accord. Avec le script hibernate, c'est vraiment devenu simple à configurer : tu fais un coup d'hibernation sans te poser de questions, tu réveilles et tu vois si qqch ne marche plus, et si oui tu le blacklist dans la conf d'hibernate, et puis voilà c'est plié. Y'a 1,5 an quand j'ai eu mon portable, j'avais eu à écrire mes propres scripts (forcement largement moins bien fichus) pour faire ça, bref ça s'est vraiment démocratisé...
> Chez moi, c'est une image de 500 mo (pour 768mo de ram) en
> moyenne qui est écrite à la suspension puis lue au démarrage
Ici sur un disque de portable à 5400 t/min (je crois), je viens de mesurer que ~480Mo étaient restaurés en ~22 secondes. Un peu plus rapide que toi donc. Est-ce que tu utilises bien la compression LZF ?
Avec le petit passage par grub, le boot du noyau de restauration et la réinitialisation d'un ou deux drivers à la fin du processus, ça me fait 30 secondes pile poil. Ça vaut vraiment le coup je trouve pour retrouver son bureau tel qu'on l'avait laissé, avec ses applis ouvertes etc.
Et puis sinon, j'utilise aussi le "suspend to RAM" quand c'est pour hiberner juste qlqs heures, genre une nuit ou le temps d'un trajet maison<-->taf. Là c'est vraiment une question de 2 ou 3 secondes pour suspendre ou réveiller, c'est franchement agréable. Mais par contre je suis pas persuadé que les PCs de bureau (non-portables quoi) soient nombreux à supporter ce mode, enfin j'en sais rien.
[^] # Re: oui et non
Posté par tipote . Évalué à 1.
Par contre, je n'ai pas encore réussi à utiliser le "suspend to ram". Peut-être que je n'ai simplement pas assez persévéré. Tu utilises aussi le script hibernate pour ça ?
[^] # Re: oui et non
Posté par tgl . Évalué à 2.
> Peut-être que je n'ai simplement pas assez persévéré. Tu utilises
> aussi le script hibernate pour ça ?
Yep, maintenant j'utilise hibernate aussi pour ça. Enfin, "hibernate-ram" pour être exact, qui est un symlink sur "hibernate", et qui utilise pour config "/etc/hibernate/ram.conf". Par rapport au "hibernate.conf", la principale différence est le mode de veille : "UseSysfsPowerState mem" au lieu du "UseSuspend2 yes".
Après, je sais pas trop, peut-être que niveau support de l'ACPI c'est un peu plus tatillon que pour le suspend-to-disk... Perso avec un IBM T40 ça fait maintenant pas mal de versions du kernel que ça passe bien, mais bon, ça peut dépendre pas mal du portable j'imagine.
[^] # Re: oui et non
Posté par tipote . Évalué à 1.
D'après l'auteur de cette page, les "frame buffers" sont actuellement incompatibles avec le suspend-to-ram. C'est justement mon cas : j'ai essayé avec radeonfb (étant donné que j'ai une radeon mobility) et vesafb, sans réussir.
[^] # Re: oui et non
Posté par tgl . Évalué à 2.
Bon après, sur cet ACER, j'en sais rien, mais c'est juste pour dire que c'est pas le framebuffer en général qui empêche le suspend-to-ram.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.