On Wed, 2007-05-30 at 10:06 -0700, Daniel Walker wrote: > On Wed, 2007-05-30 at 15:49 +0200, Ingo Molnar wrote: > > * Steven Rostedt <[EMAIL PROTECTED]> wrote: > > > > > [...] We can argue that sched_clock is "good enough". If someone > > > wants better accounting of locks on some other arch, they can simply > > > change sched_clock to be more precise. > > > > exactly. Imprecise sched_clock() if there's a better fast clock source > > available is a bug in the architecture code. If the only available > > clocksource is 1 msec resolution then there's no solution and nothing to > > talk about - lock statistics will be 1msec granular just as much as > > scheduling. > > > I don't agree .. sched_clock() is obsoleted by timekeepings clocksource > structure.. sched_clock() was a quick way to get lowlevel time stamps > just for the scheduler. The timekeeping clocksource structure is a more > complete solution. > > >From the architecture perspective there are two low level clock hooks to > implement one is sched_clock() , and at least one clocksource structure. > Both do essentially the same thing. With timekeepings clocksource > structure actually being easier to implement cause the math is built in.
I think you are mistaken here; the two are similar but not identical. I see sched_clock() as fast first, accurate second. Whereas the clocksource thing is accurate first, fast second. There is room for both of them. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
