[Pm-utils] Re: s2both

[Rafael J. Wysocki]

On Tuesday, 13 March 2007 03:43, Nigel Cunningham wrote:
> Hi.
> 
> (Adding Rafael to the recipients so he can put his 2c in too if he
> desires).

Thanks!

> On Mon, 2007-03-12 at 23:58 +0100, Tim Dijkstra wrote:
> > On Mon, 12 Mar 2007 18:10:02 -0400
> > David Zeuthen <david at fubar.dk> wrote:
> > 
> > > On Mon, 2007-03-12 at 17:37 -0400, Peter Jones wrote:
> > > > On Mon, 2007-03-12 at 15:52 -0400, David Zeuthen wrote:
> > > > 
> > > > > Peter, is this something you can look at / comment on?
> > > > 
> > > > Well, for this to work, we need the kernel to write out the data to the
> > > > swap file without powering the machine off.  This may be something we
> > > > can make the "test" support in /sys/power/disk, but that's really not
> > > > optimal, because a) it would actually mean putting all the devices to
> > > > sleep, waking them back up, and putting them to sleep again, and b)
> > > > there's a 5 second wait in the middle.
> > 
> > > That's a cryptic answer but, then again, I wasn't really clear with my
> > > questions. I'll try again:
> > 
> > Maybe I shouldn't try to guess Peters meaning, but maybe he was trying 
> > to think out an implementation of pm-is-supported. Indeed how thorough
> > should this check of `is supported' be, is an interesting question.
> > Really suspending devices and trying to write to swap for hibernate for
> > example seems a bit overkill to me...
> > But checking if the configured swap partition / file exist seems sane.
> > For uswsusp checking if the device node which is used for communication
> > with kernel is available is another.
> > For the rest I think we can assume things will work.

For uswsusp, you can try to open /dev/snapshot and do some tests.
For example, you can check if the SNAPSHOT_SET_IMAGE_SIZE ioctl works
(should work if uswsusp is supported).  The SNAPSHOT_AVAIL_SWAP should
work if the resume swap partition/file is properly configured and the
SNAPSHOT_PMOPS ioctl called with a wrong argument should return -EINVAL
if supported (otherwise -ENOTTY will be returned).

> For Suspend2, you can do:
> 
> cat /sys/power/suspend2/image_exists.
> 
> It returns...
> 
> -1 if you can't suspend at the moment (resume[2]= points to an invalid
> location;
> 0 if you can suspend and there is no image there at the mo;
> 1 if you can suspend and there is an image there at the mo;
> 
> (It can also be used from an initrd/ramfs)
> 
> Picking up on another comment, it should be possible for us to guarantee
> that you'll be able to suspend. To do that, we'd need to (on the kernel
> side...)
> 
> 1) Know how much storage will be available when we go to suspend. This
> could be achieved by not using swap (since there are other allocators).
> Suspend2 can do this at the mo, but [u]swsusp is swap centric.

For uswsusp you can use the SNAPSHOT_AVAIL_SWAP ioctl for this purpose.

> 2) Know how much memory drivers are going to need to allocate when we
> suspend them. This could be achieve with modifications to the driver
> core.
> 3) Know how much memory the suspend implementation itself is going to
> need. Can be calculated ahead of time.

Of course this will depend on the (user-controllable) image size and it really
is difficult to compute without actually freezing processes and suspending
devices.

> 4) Know whether drivers are going to succeed in suspending and resuming.
> This should get better over time.

This one is difficult.  Currently you can do:

# echo test > /sys/power/disk
# echo disk > /sys/power/state

to test the suspend/resume code to some extent.  It freezes processes,
shrinks memory, suspends devices, disables nonboot CPUs, waits for 5 sec.
and restores everything to the previous state (except for the freed memory,
of course).

Still, unfortunately, some drivers that pass this test fail during the actual
resume either from disk or from RAM.

> Reliability is really important to me too, and I'd like to work over
> time towards having a sysfs entry you can cat to definitively know
> whether you'll be able to hibernate.

Well, as far as drivers are concerned, you can't tell in whether or not you'll
be able to resume without actually trying it.

Greetings,
Rafael