Borislav Petkov <[email protected]> writes: > On Sun, May 12, 2013 at 06:13:34PM +0200, Bjørn Mork wrote: >> diff --git a/kernel/rcutree.c b/kernel/rcutree.c >> index 6934238..2dcbf84 100644 >> --- a/kernel/rcutree.c >> +++ b/kernel/rcutree.c >> @@ -3103,9 +3103,11 @@ static int rcu_pm_notify(struct notifier_block *self, >> { >> switch (action) { >> case PM_HIBERNATION_PREPARE: >> + case PM_SUSPEND_PREPARE: >> rcu_expedited = 1; >> break; >> - case PM_POST_RESTORE: >> + case PM_POST_HIBERNATION: >> + case PM_POST_SUSPEND: >> rcu_expedited = 0; >> break; >> default: > > If I'm reading Documentation/power/notifiers.txt correctly, we only need > PM_HIBERNATION_PREPARE when we go to sleep (whatever hibernation method > we use) and PM_POST_HIBERNATION when we restore.
Well, that's not the way I read it. And testing also supports that. Adding the above to your patch makes restore from suspend use < 3 seconds again. Using only PM_HIBERNATION_PREPARE had no effect on the restore from suspend time, still measured at around 15 seconds on my laptop. Note that I did not test hibernation at all. But based on your patch I assume the issue is exactly the same. > I don't think it matters for expediting RCU grace periods whether > we had an error during resume or not and I'd basically want to set > rcu_expedited to 0 unconditionally when resuming.. Yes, and I believe that's what PM_POST_HIBERNATION will achieve if I read the docs correctly. But I guess this should be sanity checked via Rafael or someone else knowing how these notifiers work. Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
