Re: [ 01/10] [Suspend2] kernel/power/modules.h

[Nigel Cunningham <nigel@suspend2.net>]

Hi.

On Thursday 02 February 2006 22:53, Rafael J. Wysocki wrote:
> Hi,
>
> On Thursday 02 February 2006 10:38, Pavel Machek wrote:
> > > Its limitation , however, is that it requires a lot of memory for the
> > > system memory snapshot which may be impractical for systems with
> > > limited RAM, and that's where your solution may be required.
> >
> > Actually, suspend2 has similar limitation. It still needs half a
> > memory free, but it does not count caches into that as it can save
> > them separately.
>
> I didn't know that.  [If that is the case, I wonder what Nigel means by
> the "whole memory image".  Nigel?]

The LRU almost always easily accounts for more 50% of memory in use. Suspend2 
writes LRU pages to disk, then uses those pages to store the atomic copy of 
the remainder of memory. That's how I overcome the 50% problem and still 
really do get a full image of memory. If the LRU is smaller than the 
remainder of memory in use, we allocate extra memory if possible. If that 
still doesn't give enough memory for the atomic copy, we seek to free memory 
until that constraint is satisfied. If we free everything we can, and still 
can't satisfy that constraint, we give up and return control to the user. In 
99% of the cases, however, no freeing of memory is required and the user 
really can get a full image of memory saved.

> > That means that on certain small systems (32MB RAM?), suspend2 is going
> > to have big advantage of responsivity after resume. But on the systems
> > where [u]swsusp can't suspend (6MB RAM?), suspend2 is not going to be
> > able to suspend, either. [Roughly; due to bugs and implementation
> > differences there may be some system size where one works and second one
> > does not, but they are pretty similar]
>
> Generally speaking, my perception is that suspend2 may be preferrable below
> 256 MB of RAM.  Moreover there are some people who seem to prefer
> entirely kernel-based suspend, and I'm not going to develop the code
> in swap.c and disk.c any further (of course with the exception of bugfixes
> etc.).  Nigel has done it already so perhaps there is a room for his code,
> too, _provided_ _that_ it is accepted.

All of the machines I regularly use have 512M+ of memory. Suspend2 is 
definitely preferable on them because I've worked hard to maximise I/O 
throughput. Last time I measured swsusp throughput, it was 16MB/s on my old 
Omnibook. Suspend2 achieved ~25MB writing and 50MB/s reading when using LZF 
compression (933 Celeron), or the 35MB/s uncompressed (the maximum throughput 
that could be achieved according to tools like hdparm -t) on the same system. 
With the same drive in my new laptop (amd64 M34), I get ~70MB/s read/write 
(depending on cpufreq settings). My 3G P4s at work and home do about 70
(w)/110(r) MB/s. (All of this is using LZF compression).

Regards,

Nigel

> Greetings,
> Rafael
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net                IRC: #suspend2 on Freenode

Attachment: pgpSqpoWAukJN.pgp
Description: PGP signature