[Q] Prefered suspend to ram or disk method ?

[Q] Prefered suspend to ram or disk method ?

[Xavier Maillard]

Hi there,

Just a quick and easy question for you.

I am aware of three ways to make my laptop suspend/hibernate:

1. suspend
2. ususpend
3. suspend2

The first two are directly part of the official linux
distribution and the third one is easy to install into it.

Here is my question: what is the recommended method ? How does
suspend compare to ususpend/suspend2 ? Is there any chance to see
suspend2 be part of the official linux distribution in a near
future or not ?

Regards,

Xavier

Re: [Q] Prefered suspend to ram or disk method ?

[Rafael J. Wysocki]

Hi,

On Sunday, 28 January 2007 10:09, Xavier Maillard wrote:
> Hi there,
> 
> Just a quick and easy question for you.
> 
> I am aware of three ways to make my laptop suspend/hibernate:
> 
> 1. suspend
> 2. ususpend
> 3. suspend2
> 
> The first two are directly part of the official linux
> distribution and the third one is easy to install into it.
> 
> Here is my question: what is the recommended method ?

Well, that depends on who you ask. ;-)

> How does suspend compare to ususpend/suspend2 ?

swsusp and ususpend use the same low-level kernel code, so if one of them
works for you, the other should as well.  The difference is mainly that with
swsusp the kernel saves the image into a swap, while with usupend the image
is saved (and loaded on resume) by a userland process.  Additionally, ususpend
can compress and/or encrypt the image, supports suspend-to-disk-and-RAM,
splash-based progress meters and some such.  Gerenally, it adds the features
that, in the opinion of its authors, are better implemented in the userland.
Plus IMHO ususpend's resume is a bit more convenient for calling from within
initrd images.

suspend2 uses some different low-level code, but as far as the stopping of
tasks and handling devices are concerned, it should be equivalent to swsusp
and ususpend.  It generally allows you to create bigger suspend images (the
images created by swsusp and ususpend are at most as large as 50% of RAM),
but it makes some strong assumptions regarding memory management which are
not proven to be always satisfied, although there's no evidence showing
otherwise.  It also implements approximately the same set of additional
features as ususpend, but in the kernel.

> Is there any chance to see suspend2 be part of the official linux
> distribution in a near future or not ?

That's a delicate matter ...

Greetings,
Rafael


-- 
If you don't have the time to read,
you don't have the time or the tools to write.
		- Stephen King

Re: [Q] Prefered suspend to ram or disk method ?

[Nigel Cunningham]

Hi.

On Sun, 2007-01-28 at 20:47 +0100, Rafael J. Wysocki wrote:
> > How does suspend compare to ususpend/suspend2 ?
> 
> swsusp and ususpend use the same low-level kernel code, so if one of them
> works for you, the other should as well.  The difference is mainly that with
> swsusp the kernel saves the image into a swap, while with usupend the image
> is saved (and loaded on resume) by a userland process.  Additionally, ususpend
> can compress and/or encrypt the image, supports suspend-to-disk-and-RAM,
> splash-based progress meters and some such.  Gerenally, it adds the features
> that, in the opinion of its authors, are better implemented in the userland.
> Plus IMHO ususpend's resume is a bit more convenient for calling from within
> initrd images.
> 
> suspend2 uses some different low-level code, but as far as the stopping of
> tasks and handling devices are concerned, it should be equivalent to swsusp
> and ususpend.  It generally allows you to create bigger suspend images (the
> images created by swsusp and ususpend are at most as large as 50% of RAM),
> but it makes some strong assumptions regarding memory management which are
> not proven to be always satisfied, although there's no evidence showing
> otherwise.  It also implements approximately the same set of additional
> features as ususpend, but in the kernel.

That's not true anymore. Suspend2 uses exactly the same lowlevel code.
It just modifies the C that runs around the lowlevel code slightly so
that suspend2 instead of swsusp code is executed before and afterwards.

Regarding the assumptions (about LRU pages not changing), I have that in
progress. The content of the LRU list definitely doesn't change, but by
calculating MD5 checksums of the changes before and after saving those
pages, we've seen some (up to 20) pages change on a few computers. I
need (obviously) to put time into finding the cause of those changes.

Regards,

Nigel

Re: [Q] Prefered suspend to ram or disk method ?

[Rafael J. Wysocki]

Hi,

On Sunday, 28 January 2007 20:57, Nigel Cunningham wrote:
> Hi.
> 
> On Sun, 2007-01-28 at 20:47 +0100, Rafael J. Wysocki wrote:
> > > How does suspend compare to ususpend/suspend2 ?
> > 
> > swsusp and ususpend use the same low-level kernel code, so if one of them
> > works for you, the other should as well.  The difference is mainly that with
> > swsusp the kernel saves the image into a swap, while with usupend the image
> > is saved (and loaded on resume) by a userland process.  Additionally, ususpend
> > can compress and/or encrypt the image, supports suspend-to-disk-and-RAM,
> > splash-based progress meters and some such.  Gerenally, it adds the features
> > that, in the opinion of its authors, are better implemented in the userland.
> > Plus IMHO ususpend's resume is a bit more convenient for calling from within
> > initrd images.
> > 
> > suspend2 uses some different low-level code, but as far as the stopping of
> > tasks and handling devices are concerned, it should be equivalent to swsusp
> > and ususpend.  It generally allows you to create bigger suspend images (the
> > images created by swsusp and ususpend are at most as large as 50% of RAM),
> > but it makes some strong assumptions regarding memory management which are
> > not proven to be always satisfied, although there's no evidence showing
> > otherwise.  It also implements approximately the same set of additional
> > features as ususpend, but in the kernel.
> 
> That's not true anymore. Suspend2 uses exactly the same lowlevel code.
> It just modifies the C that runs around the lowlevel code slightly so
> that suspend2 instead of swsusp code is executed before and afterwards.

Okay, I stand corrected.

> Regarding the assumptions (about LRU pages not changing), I have that in
> progress. The content of the LRU list definitely doesn't change, but by
> calculating MD5 checksums of the changes before and after saving those
> pages, we've seen some (up to 20) pages change on a few computers. I
> need (obviously) to put time into finding the cause of those changes.

Do I understand correctly that you:
- save the LRU,
- copy data into them,
- compute MD5 checksums of their contents,
- save the image,
- suspend,
- resume,
- load the image,
- compute MD5 checksums of the loaded data,
and the sums computed before saving the image and after loading it may differ
for up to 20 pages?

Rafael


-- 
If you don't have the time to read,
you don't have the time or the tools to write.
		- Stephen King

Re: [Q] Prefered suspend to ram or disk method ?

[Nigel Cunningham]

Hi.

On Sun, 2007-01-28 at 21:14 +0100, Rafael J. Wysocki wrote:
> > Regarding the assumptions (about LRU pages not changing), I have that in
> > progress. The content of the LRU list definitely doesn't change, but by
> > calculating MD5 checksums of the changes before and after saving those
> > pages, we've seen some (up to 20) pages change on a few computers. I
> > need (obviously) to put time into finding the cause of those changes.
> 
> Do I understand correctly that you:
> - save the LRU,
> - copy data into them,
> - compute MD5 checksums of their contents,
> - save the image,
> - suspend,
> - resume,
> - load the image,
> - compute MD5 checksums of the loaded data,
> and the sums computed before saving the image and after loading it may differ
> for up to 20 pages?

No.

At the moment, I have an option that modifies the codepath so that prior
to saving the LRU, I calculate MD5 checksums for the LRU pages, then
prior to do the atomic copy (ie after saving them), calculate the
checksums again and compare. If the checksum varies, the relevant pages
are also resaved in the atomic copy and not restored from the LRU copy
when we reload the LRU pages at resume time. 

I want to put time into finding what changes the pages. I assume it's
filesystem or raid related because raid users also occasionally report
that raid code is submitting I/O after we've started saving LRU pages
(haven't had such reports from non-raid users).

Regards,

Nigel