lkml.org 
[lkml]   [2008]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [patch 0/3] [Announcement] Performance Counters for Linux
From
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.


\
 
 \ /
  Last update: 2008-12-05 09:19    [W:1.436 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site