Re: 2.6.25-mm1: not looking good

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Ingo Molnar <mingo@...>
Cc: Andrew Morton <akpm@...>, <tglx@...>, <penberg@...>, <linux-usb@...>, <linux-kernel@...>, <linux-mm@...>, <jmorris@...>, <sds@...>
Date: Friday, April 18, 2008 - 5:54 pm

Ingo Molnar wrote:

So I pulled your tree and I would agree there was a problem.  But it
seems unrelated to kgdb.  I bisected the tree because it worked starting
with the kgdb-light merge. 

It fails once with the patch below, but it is not clear as to why other
than the lock must have something to do with it.

I'll submit a patch to the kgdb test suite to increase the amount of
loops through the single step test as it is it can definitely catch
things :-)

Jason.


From 84556fe84dd975161e70b782d7d7cc7bd080c06a Mon Sep 17 00:00:00 2001
From: Ingo Molnar <mingo@elte.hu>
Date: Thu, 28 Feb 2008 21:00:21 +0100
Subject: [PATCH 0883/1078] sched: make cpu_clock() globally synchronous

Alexey Zaytsev reported (and bisected) that the introduction of
cpu_clock() in printk made the timestamps jump back and forth.

Make cpu_clock() more reliable while still keeping it fast when it's
called frequently.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 kernel/sched.c |   52 +++++++++++++++++++++++++++++++++++++++++++++++++---
 1 files changed, 49 insertions(+), 3 deletions(-)

diff --git a/kernel/sched.c b/kernel/sched.c
index 8dcdec6..7377222 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -632,11 +632,39 @@ int sysctl_sched_rt_runtime = 950000;
  */
 #define RUNTIME_INF    ((u64)~0ULL)
 
+static const unsigned long long time_sync_thresh = 100000;
+
+static DEFINE_PER_CPU(unsigned long long, time_offset);
+static DEFINE_PER_CPU(unsigned long long, prev_cpu_time);
+
 /*
- * For kernel-internal use: high-speed (but slightly incorrect) per-cpu
- * clock constructed from sched_clock():
+ * Global lock which we take every now and then to synchronize
+ * the CPUs time. This method is not warp-safe, but it's good
+ * enough to synchronize slowly diverging time sources and thus
+ * it's good enough for tracing:
  */
-unsigned long long cpu_clock(int cpu)
+static DEFINE_SPINLOCK(time_sync_lock);
+static unsigned long long prev_global_time;
+
+static unsigned long long __sync_cpu_clock(cycles_t time, int cpu)
+{
+    unsigned long flags;
+
+    spin_lock_irqsave(&time_sync_lock, flags);
+
+    if (time < prev_global_time) {
+        per_cpu(time_offset, cpu) += prev_global_time - time;
+        time = prev_global_time;
+    } else {
+        prev_global_time = time;
+    }
+
+    spin_unlock_irqrestore(&time_sync_lock, flags);
+
+    return time;
+}
+
+static unsigned long long __cpu_clock(int cpu)
 {
     unsigned long long now;
     unsigned long flags;
@@ -657,6 +685,24 @@ unsigned long long cpu_clock(int cpu)
 
     return now;
 }
+
+/*
+ * For kernel-internal use: high-speed (but slightly incorrect) per-cpu
+ * clock constructed from sched_clock():
+ */
+unsigned long long cpu_clock(int cpu)
+{
+    unsigned long long prev_cpu_time, time, delta_time;
+
+    prev_cpu_time = per_cpu(prev_cpu_time, cpu);
+    time = __cpu_clock(cpu) + per_cpu(time_offset, cpu);
+    delta_time = time-prev_cpu_time;
+
+    if (unlikely(delta_time > time_sync_thresh))
+        time = __sync_cpu_clock(time, cpu);
+
+    return time;
+}
 EXPORT_SYMBOL_GPL(cpu_clock);
 
 #ifndef prepare_arch_switch
-- 
1.5.5


--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
2.6.25-mm1: not looking good, Andrew Morton, (Thu Apr 17, 7:03 pm)
2.6.25-mm1: Failing to probe IDE interface, Mel Gorman, (Mon Apr 28, 12:42 pm)
Re: 2.6.25-mm1: Failing to probe IDE interface, Bartlomiej Zolnierkiewicz..., (Mon Apr 28, 2:44 pm)
Re: 2.6.25-mm1: Failing to probe IDE interface, Mel Gorman, (Tue Apr 29, 5:43 am)
Re: 2.6.25-mm1: Failing to probe IDE interface, Mel Gorman, (Tue Apr 29, 11:49 am)
Re: 2.6.25-mm1: Failing to probe IDE interface, Mel Gorman, (Tue Apr 29, 12:58 pm)
Re: 2.6.25-mm1: Failing to probe IDE interface, Bartlomiej Zolnierkiewicz..., (Tue Apr 29, 5:37 pm)
Re: 2.6.25-mm1: Failing to probe IDE interface, Mel Gorman, (Wed Apr 30, 7:16 am)
Re: 2.6.25-mm1: Failing to probe IDE interface, Andrew Morton, (Mon Apr 28, 12:59 pm)
Re: 2.6.25-mm1: Failing to probe IDE interface, Mel Gorman, (Tue Apr 29, 5:39 am)
Re: 2.6.25-mm1: not looking good, Andrew Morton, (Fri Apr 18, 3:50 am)
Re: 2.6.25-mm1: not looking good, Andrew Morton, (Fri Apr 18, 3:53 am)
Re: 2.6.25-mm1: not looking good, Pavel Machek, (Fri Apr 18, 7:07 am)
Re: 2.6.25-mm1: not looking good, Pavel Machek, (Fri Apr 18, 5:42 am)
Re: 2.6.25-mm1: not looking good, Alan Stern, (Fri Apr 18, 11:22 am)
Re: 2.6.25-mm1: not looking good, Andrew Morton, (Fri Apr 18, 3:57 am)
Re: 2.6.25-mm1: not looking good, Ingo Molnar, (Fri Apr 18, 5:22 am)
Re: 2.6.25-mm1: not looking good, Ingo Molnar, (Fri Apr 18, 8:18 am)
Re: 2.6.25-mm1: not looking good, Ingo Molnar, (Fri Apr 18, 3:09 am)
Re: 2.6.25-mm1: not looking good, Pekka Enberg, (Fri Apr 18, 2:40 am)
Re: 2.6.25-mm1: not looking good, Ingo Molnar, (Fri Apr 18, 3:24 am)
Re: 2.6.25-mm1: not looking good, James Morris, (Fri Apr 18, 6:32 am)
Re: 2.6.25-mm1: not looking good, Pekka Enberg, (Fri Apr 18, 3:25 am)
Re: 2.6.25-mm1: not looking good, Andrew Morton, (Fri Apr 18, 2:56 am)
Re: 2.6.25-mm1: not looking good, Arjan van de Ven, (Fri Apr 18, 1:49 am)
Re: 2.6.25-mm1: not looking good, Andrew Morton, (Fri Apr 18, 2:10 am)
Re: 2.6.25-mm1: not looking good, Ingo Molnar, (Fri Apr 18, 3:19 am)
Re: 2.6.25-mm1: not looking good, Andrew Morton, (Fri Apr 18, 3:28 am)
Re: Stack protector build failure (was Re: 2.6.25-mm1: not l..., Arjan van de Ven, (Fri Apr 18, 12:57 pm)
Re: 2.6.25-mm1: not looking good, Ingo Molnar, (Fri Apr 18, 5:28 am)
Re: 2.6.25-mm1: not looking good, Paul Moore, (Thu Apr 17, 7:55 pm)
Re: 2.6.25-mm1: not looking good, Andrew Morton, (Thu Apr 17, 9:35 pm)
Re: 2.6.25-mm1: not looking good, Paul Moore, (Fri Apr 18, 10:57 am)
Re: 2.6.25-mm1: not looking good, Andrew Morton, (Thu Apr 17, 8:04 pm)
Re: 2.6.25-mm1: not looking good, Paul Moore, (Fri Apr 18, 10:55 am)
Re: 2.6.25-mm1: not looking good, Andrew Morton, (Thu Apr 17, 7:40 pm)
Re: 2.6.25-mm1: not looking good, Andrew Morton, (Thu Apr 17, 8:14 pm)
Re: 2.6.25-mm1: not looking good, Jason Wessel, (Thu Apr 17, 11:05 pm)
Re: 2.6.25-mm1: not looking good, Ingo Molnar, (Fri Apr 18, 3:37 am)
Re: 2.6.25-mm1: not looking good, Jason Wessel, (Fri Apr 18, 5:54 pm)
Re: 2.6.25-mm1: not looking good, Vegard Nossum, (Fri Apr 18, 7:46 am)
Re: 2.6.25-mm1: not looking good, Ingo Molnar, (Fri Apr 18, 8:34 am)
Re: 2.6.25-mm1: not looking good, Vegard Nossum, (Fri Apr 18, 8:41 am)
Re: 2.6.25-mm1: not looking good, Jason Wessel, (Fri Apr 18, 9:02 am)
Re: 2.6.25-mm1: not looking good, Vegard Nossum, (Fri Apr 18, 9:22 am)
Re: 2.6.25-mm1: not looking good, Jason Wessel, (Fri Apr 18, 9:27 am)
Re: 2.6.25-mm1: not looking good, Vegard Nossum, (Fri Apr 18, 10:47 am)
Re: 2.6.25-mm1: not looking good, Vegard Nossum, (Fri Apr 18, 12:02 pm)
Re: 2.6.25-mm1: not looking good, Greg KH, (Thu Apr 17, 7:24 pm)
Re: 2.6.25-mm1: not looking good, Kay Sievers, (Thu Apr 17, 8:48 pm)
Re: 2.6.25-mm1: not looking good, Andrew Morton, (Fri Apr 18, 12:07 am)
Re: 2.6.25-mm1: not looking good, Andrew Morton, (Thu Apr 17, 9:12 pm)
Re: 2.6.25-mm1: not looking good, Dan Williams, (Thu Apr 17, 7:24 pm)