Re: [PATCH]: In kernel hibernation, suspend to both

From: Srivatsa S. Bhat
Date: Sun May 13 2012 - 19:51:10 EST


On 05/14/2012 04:48 AM, Bojan Smojver wrote:

> On Sun, 2012-05-13 at 15:10 +0200, Rafael J. Wysocki wrote:
>>> So, a suspend after the image write will be just one long "failure",
>> after
>>> which hibernation code has to unwind again. No?
>>
>> Hmm. Good question. It should be like this I think, although there
>> may be some corner cases lurking.
>
> AFAICT, the user space suspend to both works this way.
>


But does it carry out suspend-to-ram in full, or does it skip the
PM_SUSPEND_PREPARE notifications?

> If I understand thing correctly, at the point of suspend to memory, we
> are not really running a full system any more. All the processes have
> been frozen and they've been told that hibernation is in progress. Ditto
> devices, minus the ones we use to write to swap. So, when hibernation
> code unwinds post resume from memory, it would be doing the correct
> thing.
>
> Srivatsa, does that make sense to you?
>


See my concerns about the preparation stage for suspend, in my other
mail as well. I would have been less worried if we did things in full:
1. prepare for hibernation
2. create image
3. prepare for suspend
4. do suspend
5. do resume
6. unwind from hibernation code (like a failed hibernation).

Still no guarantees, but somewhat better.
(consider what will happen if some code expects completion of an operation,
successful or otherwise, before starting another.. and hence is unprepared
for something like:
hibernation prepare -> suspend prepare -> post suspend -> post hibernation)

If we don't rework this thing carefully via a special notification for
save-image-and-suspend like what Rafael suggested, and instead try to go
with existing stuff as it is, I would definitely suggest putting this feature
under something like CONFIG_EXPERIMENTAL ;-)

Regards,
Srivatsa S. Bhat

--
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/