Re: swsusp performance problems in 2.6.15-rc3-mm1

[Pavel Machek <pavel@suse.cz>]

Hi!

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

Well, doing it in userspace means that you only pay kernel complexity
once; and then you can get encryption, compression, suspend-to-file
for free. And amount of kernel changes is surprisingly small.

Userspace recovery is not big problem, btw. First, userspace should
just work. It is doing suspend to disk, so it should better not
fail. Fortunately, during debugging I found out that being userspace
has big advantages: you can still use usual recover techniques after
segfault.

> > Interesting use, but for embedded app, they can just reserve partition
> > as well. [I have seen some patches doing that.]
> 
> For swap?

Yes. And then add some hacks to swapoff as soon as image is restored.

								Pavel
-- 
Thanks, Sharp!
-
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/