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

[Rafael J. Wysocki]

Hi,

On Friday, 16 December 2005 15:26, Christian Trefzer wrote:
> On Fri, Dec 16, 2005 at 11:16:23AM +0100, Stefan Seyfried wrote:
> > This is almost trivially solvable from userspace (not tested, beware :-):
> > - check the return code of your write() to /sys/power/state
> > - if it is ENOMEM (better look into the kernel code if this is what is
> >   actually reported...), then write "0" to image_size and try again.
> > 
> > or (not as sophisticated, and i am not sure if the paths are all correct):
> > ----
> > #!/bin/sh
> > echo 150  > /sys/power/image_size
> > echo disk > /sys/power/state
> > if [ $? -ne 0 ]; then
> >     echo 0 > /sys/power/image_size
> >     echo disk > /sys/power/state
> > fi
> > ----
> > this will retry on any error (e.g. process not stopped, no swap space
> > at all, device refused to suspend...) not only on ENOMEM, but echo
> > unfortunately does not return the error code, only success or failure.
> > Easy solution would be a small perl or C program.
> > 
> > I am not convinced that this should be handled in the kernel.
> 
> I do not see a horrific logical problem here, given that the maximum
> desired image size is the minimum of max_image_size and free swap space
> available. The main question is the one of implementation, though.

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.

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.

Greetings,
Rafael


-- 
Beer is proof that God loves us and wants us to be happy - Benjamin Franklin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/