Hi.
On Tue, 2005-12-06 at 11:37, Pavel Machek wrote:
> Hi!
>
> > > First, I don't think that saving a full image of memory is generally a good
> > > idea. It is - for systems with relatively small RAM, but for systems with
> > > more than, say, 512 MB that's questionable. Of course that depends a lot
> > > on the usage patterns of particular system, but having 768 MB of RAM
> > > in my box I wouldn't like it to save more than a half of it during suspend,
> > > for performance reasons.
> >
> > I agree that whether it's a good idea varies according to individual
> > tastes and usage. That's why I've made it configurable. The other point
> > to remember is that suspend2's I/O performance is much better. My
> > desktop here at work, for example, writes the image at 72MB/s and reads
> > it back at 116MB/s. (3GHz P4 with a Maxtor 6Y120L0). Writing 1GB at
> > these rates is not a problem.
>
> Andy reported 20MB/sec on hdparm. I do not think it is possible to
> write faster than that. And that seems about ok for notebooks, X32
> (pretty new) has:
Depending upon what speed his CPU is, he should be able to achieve close
to 40MB/s with LZF compression (assuming 50% compression and a CPU fast
enough that the disk continues to be the bottleneck).
> root@amd:~# hdparm -t /dev/hda
>
> /dev/hda:
> Timing buffered disk reads: 108 MB in 3.01 seconds = 35.85 MB/sec
>
> > > Second, IMHO, some things you are doing in suspend2, like image encryption,
> > > or accessing ordinary files, should not be implemented in the kernel.
> >
> > Image encryption is just done using cryptoapi - I just expose the
> > parameters and optionally save them in the image; there's no nous in
> > suspend2 regarding encryption beyond that.
>
> Unfortunately all these "small things" add up.
But so does doing it from userspace - you then have to make the pages
available to the userspace program, implement encryption there, provide
safety nets in case userspace dies unexpectedly and so on. There is a
cost to encryption that occurs regardless of where we do the
compressing.
> > Regarding accessing ordinary files, it's really just a variation on the
> > swapwriter in that we bmap the storage and then use the blocks we're
> > given. There were two reasons for adding this - first removing the
> > dependency on available swapspace, and secondly working towards better
> > support for embedded (write the image to a file and include the file in
> > place of a ramdisk image). The second reason might sound like fluff, but
> > I can assure you as an embedded developer myself that embedded people
> > are really interested in seeing if this technique will be a viable way
> > of speeding up boot times.
>
> Interesting use, but for embedded app, they can just reserve partition
> as well. [I have seen some patches doing that.]
For swap?
Regards,
Nigel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
