Re: [PATCH 3/5] lockstat: core infrastructure

[Peter Zijlstra <a.p.zijlstra@chello.nl>]

On Fri, 2007-06-01 at 08:26 -0700, Daniel Walker wrote:
> On Fri, 2007-06-01 at 15:12 +0200, Ingo Molnar wrote:
> > * Daniel Walker <dwalker@mvista.com> wrote:
> > 
> > > On Wed, 2007-05-30 at 19:16 +0200, Peter Zijlstra wrote:
> > 
> > > > 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.
> > > 
> > > This is true .. However, if there is a speed different it's small.
> > 
> > Ugh. Have you ever compared pmtimer (or even hpet) against TSC based 
> > sched_clock()? What you write is so wrong that it's not even funny. You 
> > keep repeating this nonsense despite having been told multiple times 
> > that you are dead wrong.
> 
> Yes I have, and your right there is a difference, and a big
> difference .. Above I was referring only to the TSC clocksource, since
> that's an apples to apples comparison .. I would never compare the TSC
> to the acpi_pm, that's no contest ..
> 
> The acpi_pm as sched_clock() with hackbench was about %25 slower, the
> pit was 10x slower approximately. (I did this months ago.)

The whole issue is that you don't have any control over what clocksource
you'll end up with. If it so happens that pmtimer gets selected your
whole box will crawl if its used liberaly, like the patch under
discussion does.

So, having two interfaces, one fast and one accurate is the right answer
IMHO.

And I agree, that if the arch has a fast clock but doesn't use it for
sched_clock() that would be a shortcoming of that arch.


-
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/