On Fri, 2007-06-01 at 20:19 +0200, Ingo Molnar wrote: > * Daniel Walker <[EMAIL PROTECTED]> wrote: > > > > > > 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 .. > > You still dont get it i think: in real life we end up using the TSC in > sched_clock() _much more often_ than we end up using the TSC for > clocksource! So your flawed suggestion does not fix anything, it in fact > introduces a really bad regression: instead of using the TSC (or > jiffies) we'd end up using the pmtimer or hpet for every lock operation > when lockstat is enabled, bringing the box to a screeching halt in > essence.
My position isn't that we should use the high level clocksource interface as it is now without changes .. That's never been my position since I've been working with it.. The high level interface will need to evolve. I'm saying we should use the clocksource structure as the main hook into the low level architecture code. > so what you suggest has a far worse effect on the _majority_ of systems > that are even interested in running lockstat, than the case you > mentioned that some seldom-used arch which is lazy about sched_clock() > falls back to jiffies granularity. It's not a big deal: the stats will > have the same granularity. (the op counts in lockstat will still be > quite useful) My suggestion is only as good as the implementation .. Your making some fairly sweeping assumption about how lockstat _would_ use the clocksources in it's final form .. So clearly lockstat has a contraint which is that it can't use slow clocks.. > sched_clock() is a 'fast but occasionally inaccurate clock', while the > GTOD clocksource is an accurate clock (but very often slow). I think we're just taking different perspectives .. The tsc clocksource is just as fast as the tsc sched_clock() , you can interchange the two without ill effects .. That's one perspective .. You can use a yet to be written API that uses the GTOD and a clocksource, and allows slow clocksources to be used in place of fast ones with really bad effects, that's another perspective .. Daniel - 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/
