Re: [RFC][PATCH 2/2] first callers of process_deny_checkpoint()

Re: [RFC][PATCH 2/2] first callers of process_deny_checkpoint()

[Rafael J. Wysocki]

On Friday, 10 of October 2008, Ingo Molnar wrote:
> 
> * Rafael J. Wysocki <rjw@sisk.pl> wrote:
> 
> > > In the long run, could we expect a (experimental) version of 
> > > hibernation that would just use this checkpointing facility to 
> > > hibernate?
> > 
> > Surely not ACPI-compliant.
> 
> what do you mean?

The ACPI spec says quite specifically what should be done while entering
hibernation and during resume from hibernation.  We're not following that
in the current code, but we can (gradually) update the code to become
ACPI-compilant in that respect.  However, if we go the checkpointing route, I
don't think that will be possible any more. 

[In short, the problem is that ACPI regards the S4 state corresponding to
hibernation as a sleep state of the system which is therefore fundamentally
different from the soft power-off state and requires special handling.]

This may be a theory etc. (I don't want to start the entire discussion about
that once again), but clearly there's a choice to be made here.  I'd prefer
hibernation to be ACPI-compliant, but if people don't want that, I won't fight
for it.

Thanks,
Rafael

Re: [RFC][PATCH 2/2] first callers of process_deny_checkpoint()

[Ingo Molnar]

* Rafael J. Wysocki <rjw@sisk.pl> wrote:

> > > Surely not ACPI-compliant.
> > 
> > what do you mean?
> 
> The ACPI spec says quite specifically what should be done while 
> entering hibernation and during resume from hibernation.  We're not 
> following that in the current code, but we can (gradually) update the 
> code to become ACPI-compilant in that respect.  However, if we go the 
> checkpointing route, I don't think that will be possible any more.

ah, i see. I did not mean to utilize any ACPI paths but simple powerdown 
or reboot.

If we checkpoint all apps to persistent disk areas (which the checkpoint 
patches in this thread are about), then we can just reboot the kernel 
and forget all its state.

That capability can be used to build a really robust hibernation 
implementation IMO: we could "hibernate/kexec" over between different 
kernel versions transparently. (only a small delay will be noticed by 
the user - if we do it smartly with in-kernel modesetting then not even 
the screen contents will be changed over this.)

	Ingo

Re: [RFC][PATCH 2/2] first callers of process_deny_checkpoint()

[Len Brown]

On Fri, 10 Oct 2008, Ingo Molnar wrote:

> 
> * Rafael J. Wysocki <rjw@sisk.pl> wrote:
> 
> > > > Surely not ACPI-compliant.
> > > 
> > > what do you mean?
> > 
> > The ACPI spec says quite specifically what should be done while 
> > entering hibernation and during resume from hibernation.  We're not 
> > following that in the current code, but we can (gradually) update the 
> > code to become ACPI-compilant in that respect.  However, if we go the 
> > checkpointing route, I don't think that will be possible any more.
> 
> ah, i see. I did not mean to utilize any ACPI paths but simple powerdown 
> or reboot.

If we don't enter ACPI S4, and instead poweroff,
then we'll lose the capability to wake the system from
devices that are capable of waking S4, but incapable of waking S5.

ie. The power button will still work, but others may not.

cheers,
-Len

> If we checkpoint all apps to persistent disk areas (which the checkpoint 
> patches in this thread are about), then we can just reboot the kernel 
> and forget all its state.
> 
> That capability can be used to build a really robust hibernation 
> implementation IMO: we could "hibernate/kexec" over between different 
> kernel versions transparently. (only a small delay will be noticed by 
> the user - if we do it smartly with in-kernel modesetting then not even 
> the screen contents will be changed over this.)

Re: [RFC][PATCH 2/2] first callers of process_deny_checkpoint()

[Rafael J. Wysocki]

On Friday, 10 of October 2008, Ingo Molnar wrote:
> 
> * Rafael J. Wysocki <rjw@sisk.pl> wrote:
> 
> > > > Surely not ACPI-compliant.
> > > 
> > > what do you mean?
> > 
> > The ACPI spec says quite specifically what should be done while 
> > entering hibernation and during resume from hibernation.  We're not 
> > following that in the current code, but we can (gradually) update the 
> > code to become ACPI-compilant in that respect.  However, if we go the 
> > checkpointing route, I don't think that will be possible any more.
> 
> ah, i see. I did not mean to utilize any ACPI paths but simple powerdown 
> or reboot.
> 
> If we checkpoint all apps to persistent disk areas (which the checkpoint 
> patches in this thread are about), then we can just reboot the kernel 
> and forget all its state.
> 
> That capability can be used to build a really robust hibernation 
> implementation IMO: we could "hibernate/kexec" over between different 
> kernel versions transparently. (only a small delay will be noticed by 
> the user - if we do it smartly with in-kernel modesetting then not even 
> the screen contents will be changed over this.)

That actually should be called a migration of VM IMO and would be a useful
functionality.  Sure.

Hibernation, however, generally involves the restoration of the hardware and
most importantly _platform_ state which IMO is impossible without the ACPI
functionality, as well as wake-up, which may depend on ACPI too.

Thanks,
Rafael