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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
