Messages in this thread | | | Date | Fri, 05 Dec 2008 00:17:17 -0800 (PST) | Subject | Re: [patch 0/3] [Announcement] Performance Counters for Linux | From | David Miller <> |
| |
From: Ingo Molnar <mingo@elte.hu> Date: Fri, 5 Dec 2008 09:11:37 +0100
> > * David Miller <davem@davemloft.net> wrote: > > > From: Peter Zijlstra <a.p.zijlstra@chello.nl> > > 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.
| |