Re: swsusp performance problems in 2.6.15-rc3-mm1

[Pavel Machek <pavel@ucw.cz>]

Hi!

> > > > * compress the image. Needs to be done in userspace, so it needs
> > > > uswsusp to be merged, first. Patches for that are available. Should
> > > > speed it up about twice.
> > > 
> > > That's not true at all. You have cryptoapi in kernel space and can
> > > easily use it - it's very similar code to what you already have for
> > > encryption. You won't get double the speed with with the deflate
> > > compressor - more like 2 or 3MB/s :(. Suspend2 gets double the speed
> > > because we use lzf, which is a logically distinction addition
> > > (implemented now as another cryptoapi plugin).
> > 
> > Well, 3MB/sec improvement will save him  seconds on 20, or something
> > like that, so I guess LZF *is* a way to go, and I'd like to keep that
> > out of kernel. And I will not accept compression into mainline swsusp;
> > did that experiment with encryption once already, and I did not like
> > the result much.
> 
> No - I didn't mean a 3MB/s improvement. I meant that you'll get about
> 3MB/s throughput. It's _very_ slow. Of course having said that, I don't
> recall now what machine I saw that on. It may well be my 933 Celeron
> (Omnibook XE3).

Ah, okay -- that means that deflate compressor is pretty much useless.

> > If goal is "make it work with least effort", answer is of course
> > suspend2; but I need someone to help me doing it right.
> 
> How do you think suspend2 does it wrong? Is it just that you think that
> everything belongs in userspace, or is there more to it?

Everything belongs in userspace... that makes it "wrong
enough". Userland and kernel programming is quite different, so any
improvements to suspend2 will be wasted, long-term. You'll make users
happy for now, but it means u-swsusp gets less users and less
developers, making "doing it right" slightly harder...
								Pavel
-- 
Thanks, Sharp!