Messages in this thread | | | Date | Tue, 7 Jul 2009 10:01:58 +0200 | Subject | Re: [PATCH] U300 sched_clock implementation | From | Linus Walleij <> |
| |
Adding in Paul M since it was his patch that was supposed to fix up a generic solution...
2009/7/7 Russell King - ARM Linux <linux@arm.linux.org.uk>: > On Tue, Jun 02, 2009 at 11:00:12AM +0200, Peter Zijlstra wrote: >> 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. > > [added Tim Bird to CC] > > So what do we do? There's apparantly been zero movement on this for > over a month, and Tim Bird is reposting his patch adding __notrace > to ARMs existing sched_clock implementations. > > Given that it seems the generic approach has died a death, I suggest we > merge Linus' U300 patch, and get Tim to redo his patch to take account > of that, and apply both. > > Then, if the generic approach eventually happens, everything can then be > fixed up. > > Alternatively, if there is movement on the generic approach... > > Discuss. >
I would really like to see Pauls work finalized, it looked very promising, and I think there was actually a rough consensus about his last patch. But I guess that will be in the 2.6.32 merge window earliest?
Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |