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:4.138 / U:0.104 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site