On Fri, 2007-06-01 at 17:52 +0200, Peter Zijlstra wrote: > 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 <[EMAIL PROTECTED]> 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.
You can have control over it, which I think the whole point of this discussion .. > So, having two interfaces, one fast and one accurate is the right answer > IMHO. In the case of lockstat you have two cases fast and functional, and non-functional .. Right now your patch has no slow and functional state. The non-functional state is even the majority from my perspective. > 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. As I said before there is no reason why and architectures should be forced to implement sched_clock() .. Is there some specific reason why you think it should be mandatory? 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/
