lkml.org 
[lkml]   [2006]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [ 01/10] [Suspend2] kernel/power/modules.h
Date
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
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2006-02-02 22:33    [W:0.490 / U:0.872 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site