Messages in this thread | | | Subject | Re: [PATCH] U300 sched_clock implementation | From | Peter Zijlstra <> | Date | Tue, 02 Jun 2009 11:00:12 +0200 |
| |
On Mon, 2009-06-01 at 09:46 +0200, Linus Walleij wrote: > 2009/5/25 Peter Zijlstra <peterz@infradead.org>: > > 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. > > Can I interpret this as Acked-by: Peter Zijlstra <peterz@infradead.org> ?
I think its best if we continue with the patch Paul Mundt has been proposing.
| |