Re: [RFC/RFT] swsusp: image size tunable (was: Re: [PATCH][mm] swsusp: limit image size)

[Christian Trefzer <ctrefzer@gmx.de>]

On Fri, Dec 16, 2005 at 07:08:56PM +0100, Rafael J. Wysocki wrote:
> Hi,
> 
> On Friday, 16 December 2005 15:26, Christian Trefzer wrote:
> > The problem is the free swap space is not constant as long as you are
> > trying to free more RAM, because some pages can get swapped out in the
> > process at any time.
> 
> To handle this properly we would have to count the amount of free swap in
> every iteration of the loop in swsusp_shrink_memory(), but I wouldn't like
> to make this function swap-dependent.

Well, I did not quite see that. Renders the problem a lot less trivial.
More on that later.


> We are going to move the image-writing and reading functionality of swsusp
> to the user space anyway and the userspace process controlling the suspend
> will solve this problem.  For now, please use workarounds like the Stefan's
> one.

In the long term, if I am correctly informed, everything should be
controlled by userspace, so it seems to me that some current problems
will be solved along the way. I am not looking for a workaround, though.
Instead I wanted to ask if there was no simple way to keep swsusp from
failing in a self-contained manner, i.e. without sneaky workarounds.
What occured to me while writing my first mail was that maybe it is not
trivial at all to determine the remaining swap space, as you already
confirmed.

My point is, that the generic algorithm to determine the maximum image
size desired by the user will, as a whole, remain the same, whether
implemented in kernel or user space. Unfortunately, I am very unfamiliar
with swsusp code and all of its implications wrt. drivers etc. - this
still holds true after looking at swsusp_shrink_memory().

But generally speaking: at some point, memory is freed for the image
creation process. Recent efforts towards tunable max_image_size make it
seem to me that we likely know beforehand, how much we are going to
free. Now say we have max_image_size of 500MB, but we know that active
swaps will hold 400MB at max. So we start out freeing enough memory for
a 400MB image, and once we're done, we notice we can only save 350MB.
Does anything keep us from reducing the image size to 350MB right now? 

Apologies for wasting your time, I am trying to get rid of my ignorance.

Yours,
Chris

Attachment: pgpkmkFsbgZpO.pgp
Description: PGP signature