public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: linux-pm@lists.linux-foundation.org
Subject: Re: Memory consumption difference between in-kernel and userspace hibernation
Date: Thu, 12 Nov 2009 22:12:23 +0100	[thread overview]
Message-ID: <20091112221223.3459b8cc@surf> (raw)
In-Reply-To: <200911122152.02671.rjw@sisk.pl>

Hello,

Thanks for your feedback.

Le Thu, 12 Nov 2009 21:52:02 +0100,
"Rafael J. Wysocki" <rjw@sisk.pl> a écrit :

> The userspace interface doesn't really allow you to write to a file.
> You can write into the area the file occupies on the partition, but
> you can't use the filesystem code for the actual writing.  At least
> you shouldn't do that.

Ah. But it seems to work fairly nicely. Why can't the filesystem code
could be used to store the resume image ? Note that my file is stored
in a separate partition, fully dedicated to storing the resume file and
mounted only at very specific points in the system lifetime.

I'm doing the following things upon suspend :

 * SNAPSHOT_FREEZE

 * SNAPSHOT_ATOMIC_SNAPSHOT, which according to my understanding is
   making a snapshot of the memory inside a copy, so that once the
   snapshot is made, the kernel can be used as usual.

 * SNAPSHOT_UNFREEZE

 * Mount my YAFFS2 filesystem that will contain the resume image

 * Read /dev/snapshot and write the result to a file in the YAFFS2
   filesystem

 * Unmount the YAFFS2 filesystem

 * Shutdown

On resume, I'm doing the following operations in a /init application in
the kernel initramfs :

 * Mount the YAFFS2 filesystem

 * Open the resume image and the /dev/snapshot device

 * Read the image from the file and write it to /dev/snapshot

 * Unmount the YAFFS2 filesystem

 * SNAPSHOT_FREEZE

 * SNAPSHOT_ATOMIC_RESTORE

And done. So my YAFFS2 filesystem is *never* mounted before taking the
snapshot or before beginning to restore the snapshot.

Isn't this safe ?

> swsusp_shrink_memory() is used by both the in-kernel code and the
> userspace code more-or-less in the same way, so it looks strange.
> How much memory is there in the system?

Not that much:

# free
              total         used         free       shared      buffers
  Mem:        26116        11264        14852            0            0
 Swap:            0            0            0
Total:        26116        11264        14852

(This is the figure without the heavy applications loaded)

> s2disk allocates a few buffers for itself, but I'm not sure if that
> matters at all.
> 
> Which version of s2disk do you use, do you have encryption enabled in
> s2disk?

I'm not using s2disk at all, so no encryption, nothing. I implemented my
own suspend/resume applications (I can show the source code if needed,
even though the code is pretty ugly).

BTW, I've done a little test: compress with LZO each page that needs to
be saved as part of the snapshot. Instead of 11419648 bytes in my case,
only 5725951 bytes (half!) would be needed to store the snapshot in
memory, reducing significantly the memory pressure caused by the
allocation of the pages needed to store the snapshot. Has this already
been considered ?

Thanks again for the feedback,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

  reply	other threads:[~2009-11-12 21:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-12 20:01 Memory consumption difference between in-kernel and userspace hibernation Thomas Petazzoni
2009-11-12 20:52 ` Rafael J. Wysocki
2009-11-12 21:12   ` Thomas Petazzoni [this message]
2009-11-13 20:05     ` Rafael J. Wysocki
2009-11-21  9:29       ` Pavel Machek
2009-11-13  9:52 ` Thomas Petazzoni
2009-11-13 16:28   ` Rafael J. Wysocki

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=20091112221223.3459b8cc@surf \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=rjw@sisk.pl \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox