Messages in this thread | | | Subject | Re: [PATCH] U300 sched_clock implementation | From | Peter Zijlstra <> | Date | Mon, 25 May 2009 15:20:27 +0200 |
| |
On Mon, 2009-05-25 at 15:01 +0200, Peter Zijlstra wrote: > On Mon, 2009-05-25 at 14:13 +0200, Linus Walleij wrote: > > 2009/5/24 Peter Zijlstra <peterz@infradead.org>: > > > > > On Sat, 2009-05-23 at 23:46 +0200, Linus Walleij wrote: > > > > > >> This overrides the global sched_clock() symbol in the Linux > > >> scheduler with a local implementation which takes advantage of > > >> the timesource in U300 giving a scheduling resolution of 1us. The > > >> solution is the same as found in the OMAP2 core code. > > > > > > We assume sched_clock() to return time in ns (e-9) resolution. > > > > Yep okay and in this case: > > > > >> + ret = (unsigned long long) u300_get_cycles(); > > >> + ret = (ret * clocksource_u300_1mhz.mult_orig) >> > > >> + clocksource_u300_1mhz.shift; > > >> + return ret; > > > > (mult_orig >> shift) == 1000 > > Ah, ok -- missed that little detail ;-) > > > So for each cycle in cyclecount register we return 1000 * cycles > > i.e 1000ns. > > > > If it looks nicer we can of course simply: > > return (unsigned long long) u300_get_cycles * 1000; > > > > But the question here is whether this resolution is enough for > > sched_clock() or if it is irrelevant to override sched_clock() > > if it cannot schedule with better precision than 1000 ns. > > No anything better than jiffies is good, 1us certainly is worth the > trouble.
One note, sched_clock() is assumed to be _cheap_. Now I assume you knew that and chose a suitable clocksource.
But that is the reason this isn't generic, non of the 'stable' clocksources on x86 are fast enough to use as sched_clock.
Of course, x86 isn't the only arch and if enough architectures do show this pattern, we could indeed think about doing this in generic code.
| |