Messages in this thread | | | Subject | Re: [PATCH] sched: Support current clocksource handling in fallback sched_clock(). | From | Peter Zijlstra <> | Date | Tue, 26 May 2009 16:38:01 +0200 |
| |
Added the generic clock and timer folks to CC.
On Tue, 2009-05-26 at 16:31 +0200, Linus Walleij wrote: > 2009/5/26 Paul Mundt <lethal@linux-sh.org>: > > > */ > > unsigned long long __attribute__((weak)) sched_clock(void) > > { > > + /* > > + * Use the current clocksource when it becomes available later in > > + * the boot process, and ensure that it has a high enough rating > > + * to make it suitable for general use. > > + */ > > + if (clock && clock->rating >= 100) > > + return cyc2ns(clock, clocksource_read(clock)); > > + > > + /* Otherwise just fall back on jiffies */ > > return (unsigned long long)(jiffies - INITIAL_JIFFIES) > > * (NSEC_PER_SEC / HZ); > > } > > This seems like it would make the patch I sent the other day > unnecessary (subject u300 sched_clock() implementation). > > It would also trim off this solution found in all OMAP platforms in > arch/arm/plat-omap/common.c > > BUT Peter Zijlstra replied to my question about why this wasn't > generic with: > > [peterz]: > > But that is the reason this isn't generic, non of the 'stable' > > clocksources on x86 are fast enough to use as sched_clock. > > Does that mean clock->rating for these clocksources is > for certain < 100? > > The definition of "rating" from the kerneldoc does not > seem to imply that, it's a subjective measure AFAICT. > > 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?
| |