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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 11 May 2013 20:04:50 +0200
From:	Bjørn Mork <bjorn@...k.no>
To:	"Paul E. McKenney" <paul.mckenney@...aro.org>
Cc:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org
Subject: Bisected post-3.9 regression: Resume takes 5 times as much time as with v3.9

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@...aro.org>
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@...aro.org>
    Signed-off-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>

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

View attachment "0001-Revert-rcu-Make-RCU_FAST_NO_HZ-take-advantage-of-num.patch" of type "text/x-diff" (25231 bytes)

View attachment "config-3.9.0+" of type "text/plain" (96608 bytes)