Re: [RFD] Perf generic context based exclusion/inclusion (was Re:[PATCH 0/4] Finer granularity and task/cgroup irq time accounting)

[Venkatesh Pallipadi]

On Thu, Nov 4, 2010 at 8:51 PM, Frederic Weisbecker <fweisbec@xxxxxxxxx> wrote:
> 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@xxxxxxxxx> wrote:
<snip>
>
>
>> - 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.
>

Agree. Sleeping context won't work in general. I was just thinking
aloud on whether there is a way to tie up sleep trace event with a pid
and mutex being held, so that something like "how long did this thread
wait in this kmalloc while being in some critical section" can be
captured. So, post processing trace events is a better option here.

Thanks,
Venki

>> - 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.
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/