public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: john stultz <johnstul@us.ibm.com>
To: Paul Mundt <lethal@linux-sh.org>
Cc: 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: Tue, 26 May 2009 16:25:03 -0700	[thread overview]
Message-ID: <1243380303.3275.40.camel@localhost> (raw)
In-Reply-To: <20090526230855.GA27218@linux-sh.org>

On Wed, 2009-05-27 at 08:08 +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.


Yea. So this is a little better. There's still a few other issues to
consider:

1) What if a clocksource is registered that has the _SCHED_CLOCK bit
set, but is not selected for timekeeping due it being unstable like the
TSC?

2) Conditionally returning jiffies if the lock is held seems troubling.
Might get some crazy values that way.

thanks
-john


> ---
> 
>  include/linux/clocksource.h |    2 ++
>  kernel/sched_clock.c        |   22 ++++++++++++++++++++++
>  2 files changed, 24 insertions(+)
> 
> 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);
>  }


  parent reply	other threads:[~2009-05-26 23:25 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
2009-05-26 23:25         ` john stultz [this message]
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=1243380303.3275.40.camel@localhost \
    --to=johnstul@us.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=hskinnemoen@atmel.com \
    --cc=johnstul@linux.vnet.ibm.com \
    --cc=lethal@linux-sh.org \
    --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