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

[Stefan Seyfried]

On Thu, Dec 15, 2005 at 06:09:03PM -0800, Andy Isaacson wrote:
 
> I did have one concerning failure during an earlier test, though - I
> have only 512MB of swap with 1.25GB RAM.  Now obviously if there are
> >500MB user pages, swsusp must fail; but I think I had a failure even
> though there was only about 400MB user pages - some of it was swapped
> out, and I had image_size=500, which resulted in an image that would not
> fit into the available swap space.
> 
> It sucks to fail the suspend just because the chosen image size didn't
> fit into the current state of the machine.  Now obviously I need to
> resize my swap partition to prevent this from happening, but it would
> be nice if swsusp would automatically "try harder!" if appropriate.

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.
-- 
Stefan Seyfried                  \ "I didn't want to write for pay. I
QA / R&D Team Mobile Devices      \ wanted to be paid for what I write."
SUSE LINUX Products GmbH, Nürnberg \                    -- Leonard Cohen
-
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/