LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Nigel Cunningham <nigel@nigel.suspend2.net>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Xavier Maillard <zedek@gnu.org>, linux-kernel@vger.kernel.org
Subject: Re: [Q] Prefered suspend to ram or disk method ?
Date: Mon, 29 Jan 2007 08:02:40 +1100	[thread overview]
Message-ID: <1170018160.25406.30.camel@nigel.suspend2.net> (raw)
In-Reply-To: <200701282114.02539.rjw@sisk.pl>

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


      reply	other threads:[~2007-01-28 21:02 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
2007-01-28 20:14     ` Rafael J. Wysocki
2007-01-28 21:02       ` Nigel Cunningham [this message]

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=1170018160.25406.30.camel@nigel.suspend2.net \
    --to=nigel@nigel.suspend2.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rjw@sisk.pl \
    --cc=zedek@gnu.org \
    --subject='Re: [Q] Prefered suspend to ram or disk method ?' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).