From: Ingo Molnar <mingo@xxxxxxx> Date: Fri, 5 Dec 2008 09:11:37 +0100 > > * David Miller <davem@xxxxxxxxxxxxx> wrote: > > > From: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx> > > Date: Fri, 05 Dec 2008 09:03:36 +0100 > > > > > On Fri, 2008-12-05 at 18:57 +1100, Paul Mackerras wrote: > > > > Peter Zijlstra writes: > > > > > > > > > So, while most people would not consider two consecutive read() ops to > > > > > be close or near the same time, due to preemption and such, that is > > > > > taken away by the fact that the counters are task local time based - so > > > > > preemption doesn't affect thing. Right? > > > > > > > > I'm sorry, I don't follow the argument here. What do you mean by > > > > "task local time based"? > > > > > > time only flows when the task is running. > > > > These things aren't measuring time, or even just cycles, they are > > measuring things like L2 cache misses, cpu cycles, and other similar > > kinds of events. > > > > So these counters are going to measure all of the damn crap assosciated > > with doing the read() call as well as the real work the task does. > > that's wrong, look at the example we posted - see it pasted below. It's still too simple to be useful. There are so many aspects other than the immediate PC that monitoring tasks want to inspect when a counter overflows. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
