Re: swsusp performance problems in 2.6.15-rc3-mm1

[Pavel Machek <pavel@suse.cz>]

Hi!

[BTW right function to modify is swsusp_shrink_memory, it is quite
clear what it is doing, so finding formula that frees enough to make
it fast but not so much to make it unresponsive should be easy.]

> > Other possible ideas are:
> > 
> > * get suspend to RAM working if you want it *really* fast :-)
> 
> That's not apples with apples though. If you have a hopeless battery, as
> many do, suspend to ram is only good if you're moving from one power
> point to another.

Yes, it is not completely fair. But as I started to use X32 with good
battery... well I'm not really using swsusp any more.

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

If goal is "make it work with least effort", answer is of course
suspend2; but I need someone to help me doing it right.

> > * and of course you can apply one very big patch and do all of the
> > above :-).
> 
> Could you stop being nasty, please?

Sorry, I was trying to be funny.
								Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.
-
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/