[PATCH, RFC] use hrtimer in sched_clock

[PATCH, RFC] use hrtimer in sched_clock

[Uwe Kleine-König]

This should make it unnecessary to overwrite sched_clock for a higher
precision.
With this patch I get sub-jiffie timing with CONFIG_PRINTK_TIME=y.

Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
---
Hello,

I tested the patch on arch-arm/mach-ns9xxx and it seem seams to work.
But I admit I didn't test it deeply and I didn't measure if there is any
overhead.

Best regards
Uwe

 kernel/sched_clock.c      |    6 +++++-
 kernel/time/timekeeping.c |   16 +++++++++-------
 2 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/kernel/sched_clock.c b/kernel/sched_clock.c
index ce05271..12daf55 100644
--- a/kernel/sched_clock.c
+++ b/kernel/sched_clock.c
@@ -242,5 +242,9 @@ EXPORT_SYMBOL_GPL(sched_clock_idle_wakeup_event);
  */
 unsigned long long __attribute__((weak)) sched_clock(void)
 {
-	return (unsigned long long)jiffies * (NSEC_PER_SEC / HZ);
+	struct timespec ts;
+
+	ktime_get_ts(&ts);
+
+	return (long long)ts.tv_sec * NSEC_PER_SEC + ts.tv_nsec;
 }
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index e91c29f..49412f2 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -67,16 +67,18 @@ struct clocksource *clock;
 static inline s64 __get_nsec_offset(void)
 {
 	cycle_t cycle_now, cycle_delta;
-	s64 ns_offset;
+	s64 ns_offset = 0;
 
-	/* read clocksource: */
-	cycle_now = clocksource_read(clock);
+	if (likely(clock)) {
+		/* read clocksource: */
+		cycle_now = clocksource_read(clock);
 
-	/* calculate the delta since the last update_wall_time: */
-	cycle_delta = (cycle_now - clock->cycle_last) & clock->mask;
+		/* calculate the delta since the last update_wall_time: */
+		cycle_delta = (cycle_now - clock->cycle_last) & clock->mask;
 
-	/* convert to nanoseconds: */
-	ns_offset = cyc2ns(clock, cycle_delta);
+		/* convert to nanoseconds: */
+		ns_offset = cyc2ns(clock, cycle_delta);
+	}
 
 	return ns_offset;
 }
-- 
1.5.6.2

Re: [PATCH, RFC] use hrtimer in sched_clock

[Thomas Gleixner]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 977 bytes --]

On Fri, 11 Jul 2008, Uwe Kleine-König wrote:
> This should make it unnecessary to overwrite sched_clock for a higher
> precision.
> With this patch I get sub-jiffie timing with CONFIG_PRINTK_TIME=y.
> 
> Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@elte.hu>
> ---
> Hello,
> 
> I tested the patch on arch-arm/mach-ns9xxx and it seem seams to work.
> But I admit I didn't test it deeply and I didn't measure if there is any
> overhead.

There is lots of overhead and your approach is simply wrong. 

>  unsigned long long __attribute__((weak)) sched_clock(void)

The correct way to solve it is to override sched_clock() with a high
resolution implementation for your hardware platform. sched_clock is a
weak function to provide a default implementation based on jiffies.

If you do a grep -r sched_clock arch/arm you'll find a couple of
examples how to override sched_clock().

Thanks,

	tglx

Re: [PATCH, RFC] use hrtimer in sched_clock

[Uwe Kleine-König]

Hello Thomas,

Thomas Gleixner wrote:
> On Fri, 11 Jul 2008, Uwe Kleine-König wrote:
> > This should make it unnecessary to overwrite sched_clock for a higher
> > precision.
> > With this patch I get sub-jiffie timing with CONFIG_PRINTK_TIME=y.
> >
> > Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Ingo Molnar <mingo@elte.hu>
> > ---
> > Hello,
> >
> > I tested the patch on arch-arm/mach-ns9xxx and it seem seams to work.
> > But I admit I didn't test it deeply and I didn't measure if there is any
> > overhead.
> 
> There is lots of overhead and your approach is simply wrong.
I expected to have some overhead, but can you please elaborate on
"simply wrong"?
I will try to measure the actual overhead but cannot promise to find
time for that in the near future.
 
> >  unsigned long long __attribute__((weak)) sched_clock(void)
> 
> The correct way to solve it is to override sched_clock() with a high
> resolution implementation for your hardware platform. sched_clock is a
> weak function to provide a default implementation based on jiffies.
> 
> If you do a grep -r sched_clock arch/arm you'll find a couple of
> examples how to override sched_clock().
I new that and my purpose was to make this unneeded.  Would be nice,
wouldn't it?

Thanks and best regards,
Uwe

-- 
Uwe Kleine-König, Software Engineer
Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany
Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962

Re: [PATCH, RFC] use hrtimer in sched_clock

[Thomas Gleixner]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1173 bytes --]

On Mon, 14 Jul 2008, Uwe Kleine-König wrote:
> > > I tested the patch on arch-arm/mach-ns9xxx and it seem seams to work.
> > > But I admit I didn't test it deeply and I didn't measure if there is any
> > > overhead.
> > 
> > There is lots of overhead and your approach is simply wrong.
> I expected to have some overhead, but can you please elaborate on
> "simply wrong"?

It's wrong because it has a locking problem vs. xtime lock. Try
printk() in a code region which has xtime_lock write locked.

> > If you do a grep -r sched_clock arch/arm you'll find a couple of
> > examples how to override sched_clock().
> I new that and my purpose was to make this unneeded.  Would be nice,
> wouldn't it?

It would be nice, but it's simply not possible as each hardware
platform has a different hardware which is used for that. Also your
approach enforces that the hardware which is used for sched_clock is
the same as the one which is used for timekeeping. That's not
necessarily a good idea as we can use a less accurate and less
reliable hardware for sched_clock() than for timekeeping and we want
to do that when the sched_clock() hardware is faster to access.

Thanks,

	tglx