Bisected post-3.9 regression: Resume takes 5 times as much time as with v3.9

From: BjÃrn Mork
Date: Sat May 11 2013 - 14:05:39 EST


Hello,

resuming from system suspend is intolerably slow in current mainline. I
am not the most patient person around, and I actually started out
bisecting this believing it was hanging... Turned out it wasn't really
hanging. It just took 15 seconds to wake up from suspend-to-ram.
Timing v3.9 I found that it used less than 3 seconds on this ancient
laptop I'm using.

Bisecting it ended up pointing to

commit c0f4dfd4f90f1667d234d21f15153ea09a2eaa66
Author: Paul E. McKenney <paul.mckenney@xxxxxxxxxx>
Date: Fri Dec 28 11:30:36 2012 -0800

rcu: Make RCU_FAST_NO_HZ take advantage of numbered callbacks

Because RCU callbacks are now associated with the number of the grace
period that they must wait for, CPUs can now take advance callbacks
corresponding to grace periods that ended while a given CPU was in
dyntick-idle mode. This eliminates the need to try forcing the RCU
state machine while entering idle, thus reducing the CPU intensiveness
of RCU_FAST_NO_HZ, which should increase its energy efficiency.

Signed-off-by: Paul E. McKenney <paul.mckenney@xxxxxxxxxx>
Signed-off-by: Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx>



Being a big patch, I'm pretty sure that the problem is some minor
issue. But rather than trying to userstand this, just tried reverting
it on top of the current mainline and can confirm that this fixes the
regression. I'll leave the understanding to you :)

I'm attaching the revert patch as I had to fix a conflict, and may have
done something wrong there. I'm also attaching my .config.

Let me know if you need more information, or want me to try out proposed
fixes.



BjÃrn