LKML Archive on
help / color / mirror / Atom feed
From: Nigel Cunningham <>
To: "Rafael J. Wysocki" <>
Cc: Xavier Maillard <>,
Subject: Re: [Q] Prefered suspend to ram or disk method ?
Date: Mon, 29 Jan 2007 06:57:38 +1100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>


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.



  reply	other threads:[~2007-01-28 19:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-28  9:09 Xavier Maillard
2007-01-28 19:47 ` Rafael J. Wysocki
2007-01-28 19:57   ` Nigel Cunningham [this message]
2007-01-28 20:14     ` Rafael J. Wysocki
2007-01-28 21:02       ` Nigel Cunningham

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \
    --subject='Re: [Q] Prefered suspend to ram or disk method ?' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).