public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Mundt <lethal@linux-sh.org>
To: Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Linus Walleij <linus.ml.walleij@gmail.com>,
	Ingo Molnar <mingo@elte.hu>, Andrew Victor <linux@maxim.org.za>,
	Haavard Skinnemoen <hskinnemoen@atmel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-sh@vger.kernel.org,
	linux-arm-kernel@lists.arm.linux.org.uk,
	John Stultz <johnstul@linux.vnet.ibm.com>
Subject: Re: [PATCH] sched: Support current clocksource handling in fallback sched_clock().
Date: Wed, 27 May 2009 08:13:13 +0900	[thread overview]
Message-ID: <20090526231313.GB27218@linux-sh.org> (raw)
In-Reply-To: <20090526230855.GA27218@linux-sh.org>

On Wed, May 27, 2009 at 08:08:55AM +0900, Paul Mundt wrote:
> On Tue, May 26, 2009 at 10:17:02PM +0200, Thomas Gleixner wrote:
> > On Tue, 26 May 2009, Peter Zijlstra wrote:
> > > On Tue, 2009-05-26 at 16:31 +0200, Linus Walleij wrote:
> > > > The definition of "rating" from the kerneldoc does not
> > > > seem to imply that, it's a subjective measure AFAICT.
> > 
> >   Right, there is no rating threshold defined, which allows to deduce
> >   that. The TSC on x86 which might be unreliable, but usable as
> >   sched_clock has an initial rating of 300 which can be changed later
> >   on to 0 when the TSC is unusable as a time of day source. In that
> >   case clock is replaced by HPET which has a rating > 100 but is
> >   definitely not a good choice for sched_clock
> > 
> > > > Else you might want an additional criteria, like
> > > > cyc2ns(1) (much less than) jiffies_to_usecs(1)*1000
> > > > (however you do that the best way)
> > > > so you don't pick something
> > > > that isn't substantially faster than the jiffy counter atleast?
> > 
> >   What we can do is add another flag to the clocksource e.g.
> >   CLOCK_SOURCE_USE_FOR_SCHED_CLOCK and check this instead of the
> >   rating.
> > 
> Ok, so based on this and John's locking concerns, how about something
> like this? It doesn't handle the wrapping cases, but I wonder if we
> really want to add that amount of logic to sched_clock() in the first
> place. Clocksources that wrap frequently could either leave the flag
> unset, or do something similar to the TSC code where the cyc2ns shift is
> used. If this is something we want to handle generically, then I'll have
> a go at generalizing the TSC cyc2ns scaling bits for the next spin.
> 
Lets try that again..

---

 include/linux/clocksource.h |    2 ++
 kernel/sched_clock.c        |   22 ++++++++++++++++++++++
 kernel/time/clocksource.c   |    2 +-
 3 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
index c56457c..cfd873e 100644
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -203,6 +203,7 @@ struct clocksource {
 };
 
 extern struct clocksource *clock;	/* current clocksource */
+extern spinlock_t clocksource_lock;
 
 /*
  * Clock source flags bits::
@@ -212,6 +213,7 @@ extern struct clocksource *clock;	/* current clocksource */
 
 #define CLOCK_SOURCE_WATCHDOG			0x10
 #define CLOCK_SOURCE_VALID_FOR_HRES		0x20
+#define CLOCK_SOURCE_USE_FOR_SCHED_CLOCK	0x40
 
 /* simplify initialization of mask field */
 #define CLOCKSOURCE_MASK(bits) (cycle_t)((bits) < 64 ? ((1ULL<<(bits))-1) : -1)
diff --git a/kernel/sched_clock.c b/kernel/sched_clock.c
index e1d16c9..c7027cd 100644
--- a/kernel/sched_clock.c
+++ b/kernel/sched_clock.c
@@ -30,6 +30,7 @@
 #include <linux/percpu.h>
 #include <linux/ktime.h>
 #include <linux/sched.h>
+#include <linux/clocksource.h>
 
 /*
  * Scheduler clock - returns current time in nanosec units.
@@ -38,6 +39,27 @@
  */
 unsigned long long __attribute__((weak)) sched_clock(void)
 {
+	/*
+	 * Use the current clocksource when it becomes available later in
+	 * the boot process. As this needs to be fast, we only make a
+	 * single pass at grabbing the spinlock. If the clock is changing
+	 * out from underneath us, fall back on jiffies and try it again
+	 * the next time around.
+	 */
+	if (clock && _raw_spin_trylock(&clocksource_lock)) {
+		/*
+		 * Only use clocksources suitable for sched_clock()
+		 */
+		if (clock->flags & CLOCK_SOURCE_USE_FOR_SCHED_CLOCK) {
+			cycle_t now = cyc2ns(clock, clocksource_read(clock));
+			_raw_spin_unlock(&clocksource_lock);
+			return now;
+		}
+
+		_raw_spin_unlock(&clocksource_lock);
+	}
+
+	/* If all else fails, fall back on jiffies */
 	return (unsigned long long)(jiffies - INITIAL_JIFFIES)
 					* (NSEC_PER_SEC / HZ);
 }
diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index 80189f6..437a6cf 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -127,7 +127,7 @@ static struct clocksource *curr_clocksource = &clocksource_jiffies;
 static struct clocksource *next_clocksource;
 static struct clocksource *clocksource_override;
 static LIST_HEAD(clocksource_list);
-static DEFINE_SPINLOCK(clocksource_lock);
+DEFINE_SPINLOCK(clocksource_lock);
 static char override_name[32];
 static int finished_booting;
 

  reply	other threads:[~2009-05-26 23:13 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-26  6:15 [PATCH] sched: Support current clocksource handling in fallback sched_clock() Paul Mundt
2009-05-26 14:31 ` Linus Walleij
2009-05-26 14:38   ` Peter Zijlstra
2009-05-26 20:17     ` Thomas Gleixner
2009-05-26 23:08       ` Paul Mundt
2009-05-26 23:13         ` Paul Mundt [this message]
2009-05-26 23:25         ` john stultz
2009-05-26 23:44           ` Paul Mundt
2009-05-27  0:18             ` Thomas Gleixner
2009-05-27  0:22             ` john stultz
2009-05-27  0:26               ` Paul Mundt
2009-05-27  1:09                 ` john stultz
2009-05-27  0:27               ` Thomas Gleixner
2009-05-26 23:49         ` Thomas Gleixner
2009-05-27  0:15           ` Paul Mundt
2009-05-27 16:25             ` Daniel Walker
2009-05-28  8:44               ` Paul Mundt
2009-05-28  9:19               ` Paul Mundt
2009-05-28  9:34                 ` Peter Zijlstra
2009-05-28 11:09                   ` Paul Mundt
2009-05-28 12:22                     ` Thomas Gleixner
2009-05-28 12:40                       ` Peter Zijlstra
2009-05-28 12:42                       ` Paul Mundt
2009-05-28 12:53                         ` Thomas Gleixner
2009-05-28 12:59                         ` Peter Zijlstra
2009-05-28 13:20                           ` Paul Mundt
2009-05-28 16:13                           ` Daniel Walker
2009-05-28 16:32                             ` Peter Zijlstra
2009-05-28 16:40                               ` Paul Mundt
2009-05-28 16:52                                 ` Daniel Walker
2009-05-28 16:58                                   ` Paul Mundt
2009-05-28 17:38                                     ` Daniel Walker
2009-05-28 17:46                                       ` Thomas Gleixner
2009-05-28 17:53                                       ` Paul Mundt
2009-05-28 18:10                                         ` Daniel Walker
2009-05-28 18:27                                           ` Paul Mundt
2009-05-28 19:04                                             ` Daniel Walker
2009-05-28 19:34                                               ` Paul Mundt
2009-05-28 19:41                                                 ` Daniel Walker
2009-05-28 23:37                                                   ` Paul Mundt
2009-05-28 18:44                                           ` Thomas Gleixner
2009-05-28 17:00                                   ` Thomas Gleixner
2009-05-28 17:07                                 ` John Stultz
2009-05-26 20:23     ` john stultz
2009-05-26 20:30       ` Peter Zijlstra
2009-05-26 20:40         ` john stultz
2009-05-26 20:55           ` Peter Zijlstra
2009-05-26 23:00             ` john stultz
2009-05-26 23:24               ` Mangalampalli, JayantX
2009-05-27  0:04                 ` Thomas Gleixner
2009-05-26 23:39               ` Thomas Gleixner
2009-05-27  6:58               ` Peter Zijlstra
2009-05-26 20:39       ` Thomas Gleixner
2009-05-26 14:43   ` Paul Mundt
2009-05-26 14:50     ` Peter Zijlstra
2009-05-26 14:53       ` Paul Mundt
2009-05-26 15:02   ` Matthieu CASTET

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090526231313.GB27218@linux-sh.org \
    --to=lethal@linux-sh.org \
    --cc=akpm@linux-foundation.org \
    --cc=hskinnemoen@atmel.com \
    --cc=johnstul@linux.vnet.ibm.com \
    --cc=linus.ml.walleij@gmail.com \
    --cc=linux-arm-kernel@lists.arm.linux.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux@maxim.org.za \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox