linux-kernel - large intermittent latency spike 2.6.28 (and 2.6.27.10), bisect commit ca7e716c7833aeaeb8fedd6d004c5f5d5e14d325 -> Revert "sched_clock: prevent scd->clock from moving backwards"

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]

Message-ID: <495A96FF.1000200@jaysonking.com>
Date:	Tue, 30 Dec 2008 15:47:43 -0600
From:	Jayson King <dev@...sonking.com>
To:	linux-kernel@...r.kernel.org
CC:	mingo@...e.hu, torvalds@...ux-foundation.org,
	a.p.zijlstra@...llo.nl, shaggy@...ux.vnet.ibm.com, rjw@...k.pl,
	fabio.comolli@...il.com
Subject: large intermittent latency spike 2.6.28 (and 2.6.27.10), bisect commit
 ca7e716c7833aeaeb8fedd6d004c5f5d5e14d325 -> Revert "sched_clock: prevent
 scd->clock from moving backwards"

Greetings,

I noticed large latency spikes in 2.6.28 (and 2.6.27.10) which would 
make the system unresponsive for minutes at a time (alt+Fn switching 
wouldn't even work) when the system is under load. I could trigger the 
latency by running a large make -j 3. Sometimes it would trigger in a 
few seconds other times it would take a few minutes.

I bisected it in 2.6.27.10 to d9a888b061f55534016d2d86a21639948312a117 
-> Revert "sched_clock: prevent scd->clock from moving backwards" 
(ca7e716c7833aeaeb8fedd6d004c5f5d5e14d325 in 2.6.28) and reverting it in 
2.6.28 make the latency spike go away. At least, so far no spike in over 
24 hours.

.config and dmesg from vanilla 2.6.28 is attached.

Here's the commit:

------------------------------------
From: Linus Torvalds <torvalds@...ux-foundation.org>
Date: Sun, 14 Dec 2008 23:46:01 +0000 (-0800)
Subject: Revert "sched_clock: prevent scd->clock from moving backwards"
X-Git-Tag: v2.6.28-rc9~27
X-Git-Url: 
http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=ca7e716c7833aeaeb8fedd6d004c5f5d5e14d325

Revert "sched_clock: prevent scd->clock from moving backwards"

This reverts commit 5b7dba4ff834259a5623e03a565748704a8fe449, which
caused a regression in hibernate, reported by and bisected by Fabio
Comolli.

This revert fixes

 http://bugzilla.kernel.org/show_bug.cgi?id=12155
 http://bugzilla.kernel.org/show_bug.cgi?id=12149

Bisected-by: Fabio Comolli <fabio.comolli@...il.com>
Requested-by: Rafael J. Wysocki <rjw@...k.pl>
Acked-by: Dave Kleikamp <shaggy@...ux.vnet.ibm.com>
Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc: Ingo Molnar <mingo@...e.hu>
Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>
---

diff --git a/kernel/sched_clock.c b/kernel/sched_clock.c
index 8178724..e8ab096 100644
--- a/kernel/sched_clock.c
+++ b/kernel/sched_clock.c
@@ -118,13 +118,13 @@ static u64 __update_sched_clock(struct 
sched_clock_data *scd, u64 now)
 
     /*
      * scd->clock = clamp(scd->tick_gtod + delta,
-     *              max(scd->tick_gtod, scd->clock),
-     *              max(scd->clock, scd->tick_gtod + TICK_NSEC));
+     *               max(scd->tick_gtod, scd->clock),
+     *               scd->tick_gtod + TICK_NSEC);
      */
 
     clock = scd->tick_gtod + delta;
     min_clock = wrap_max(scd->tick_gtod, scd->clock);
-    max_clock = wrap_max(scd->clock, scd->tick_gtod + TICK_NSEC);
+    max_clock = scd->tick_gtod + TICK_NSEC;
 
     clock = wrap_max(clock, min_clock);
     clock = wrap_min(clock, max_clock);
------------------------------------

View attachment ".config" of type "text/plain" (58585 bytes)

View attachment "dmesg-2.6.28" of type "text/plain" (71821 bytes)