lkml.org 
[lkml]   [2010]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFD] Perf generic context based exclusion/inclusion (was Re: [PATCH 0/4] Finer granularity and task/cgroup irq time accounting)
On Thu, Nov 04, 2010 at 12:46:42PM -0700, Venkatesh Pallipadi wrote:
> On Thu, Nov 4, 2010 at 8:40 AM, Frederic Weisbecker <fweisbec@gmail.com> wrote:
> > (Answering thousand years later)
> >
> > Concerning the softirq/hardirq filtering in perf, this is still
> > something I want to do,
> > but now I think we should do it differently, especially we should
> > extend the idea of exclusion to the generic level.
> >
> > A "context" is a generic idea: this is something that starts and ends
> > at specific events. It means this can be expressed with
> > perf events, for example:
> >
> > - a context of "lock X held" starts when X is acquired and stops when
> > X is released
> > - a context of "irq" starts when we enter irq and ends when we exits irq.
> >
>
> I think this is will be a useful abstraction to have, mostly beyond
> just irq/softirq. Couple of comments:
> - For locks, we may want to track both "wait context" and "hold context"



Sure. In which case you want to play with both lock_acquire and lock_acquired
events. ^

lock_acquire is the "I request this lock" event.
lock_acquired is the "I have grabed this lock" event.

Well, there might be some time between the two events due to various
things, mainly lockdep checks I guess because those events are very
tight to lockdep internals (or lockstats). If you want to
know if there has been some waiting for the lock, you need lock_contended
event.

So, you can play some games here with those events.


> - This may be a bit odd and probably there is some other way of doing
> this better. But, one other context we may want to track is the sleep
> or wait at certain points. What I am thinking is something like how
> long are we waiting on this kmalloc when we are holding this mutex
> kind of info. May be it is best to do this as having sleep in kmalloc
> as a context.



If I understand you well, you want to define a context made of a
sleeping time?

The problem is that it means defining an empty context:
nothing happens in task X while it is sleeping (by definition), so
capturing any events, or counting whatever counter in this slice
would never report anything.

OTOH you can capture trace events and get the time between a
sleep and a wake up event, then you can compute the difference
from a post processing script in perf tools.



> - Few other examples of this being useful is to count events only when
> these two or more locks are held together or how long we were waiting
> on one spinlock while we are holding one spinlock.


Agreed. For that you can combine two levels of contexts, let's say you want
to count instructions when we hold lock Y when we also hold lock X
(the lock dependency order beeing X -> Y), but you don't want to count
when you hold Y without X:

- create two perf events: lock_acquire and lock_release, apply filter on lock name X
- create two perf events: lock_acquire and lock_release, apply filter on lock name Y
- apply the first pair of lock events as an inclusive context for the second pair
(which means the second pair must only count/sample on the context delimited by the
first pair)
- create a perf event that count instructions, apply the second above pair as an
inclusive context.




\
 
 \ /
  Last update: 2010-11-05 04:53    [W:0.022 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site