Re: [PATCH RFC -tip 0/6] perf: IRQ-bound performance events

[Frederic Weisbecker]

On Mon, Jun 03, 2013 at 02:22:23PM +0200, Ingo Molnar wrote:
> 
> * Alexander Gordeev <agordeev@xxxxxxxxxx> wrote:
> 
> > This patchset is against perf/core branch.
> > 
> > As Linux is able to measure task-bound and CPU-bound performance
> > events there are no convenient means to monitor performance of
> > an execution context which requires control and tuning probably
> > most - interrupt service routines.
> > 
> > This series is an attempt to introduce IRQ-bound performance
> > events - ones that only count in a context of a hardware interrupt
> > handler.
> > 
> > The implementation is pretty straightforward: an IRQ-bound event
> > is registered with the IRQ descriptor and gets enabled/disabled
> > using new PMU callbacks: pmu_enable_irq() and pmu_disable_irq().
> > 
> > The series has not been tested thoroughly and is a concept proof
> > rather than a decent implementation: no group events could be be
> > loaded, inappropriate (i.e. software) events are not rejected,
> > only Intel and AMD PMUs were tried for 'perf stat', only Intel
> > PMU works with precise events. Perf tool changes are just a hack.
> > 
> > Yet, I would like first to ensure if the approach taken is not
> > screwed and I did not miss anything vital. Not to mention if the
> > change is wanted at all.
> > 
> > Below is a sample session on a machine with x2apic in cluster mode.
> > IRQ number is passed using new argument -I <irq> (please nevermind
> > '...process id '8'...' in the output for now):
> 
> Looks useful.
> 
> I think the main challenges are:
> 
>  - Creating a proper ABI for all this:
> 
>    - IRQ numbers alone are probably not specific enough: we'd also want to 
>      be more specific to match on handler names - or handler numbers if
>      the handler name is not unique.
> 
>    - another useful variant would be where IRQ numbers are too specific:
>      something like 'perf top irq' would be a natural thing to do, to see 
>      only overhead in hardirq execution - without limiting it to a
>      specific handler. An 'all irq contexts' wildcard concept?
> 
>  - Covering softirqs as well. If we handle both hardirqs and softirqs,
>    then we are pretty much feature complete: all major context types that 
>    the Linux kernel cares about are covered in instrumentation. For things
>    like networking the softirq overhead is obviously very important, and 
>    for example on routers it will do most of the execution.
> 
>  - Covering threaded IRQs as well, in a similar model. So if someone types
>    'perf top irq', and some IRQ handlers are running threaded, those
>    should probaby be included as well.
> 
>  - Making the tooling friendlier: 'perf top irq' would be useful, and
>    accepting handler names would be useful as well.

How about we define finegrained context on top of perf events themselves?
Like we could tell perf to count a task's instructions only after
tracepoint:irq_entry is hit and stop counting when tracepoint:irq_exit.

This way we can define any kind of fine grained context, not just irqs. We
are not short on tracepoints, software events, breakpoints, kprobes, uprobes
to play Legos there.

I had a branch with a working draft of that:

  git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
  	perf/custom-ctx-v2-pre

Frederic Weisbecker (5):
      perf: Starter and stopper events
      perf: New enable_on_starter attribute
      perf: Support for starter and stopper in tools
      perf: New --enable-on-starter option
      perf: Add TODOs for event defined context

It needs quite some improvements, (some are listed in the TODO on the last commit)
especially in both the kernel and user interfaces.

Jiri had some nice ideas about it.

Also Peter was unhappy about how starter/stopper events were inherited in children
events because it complicated the inheritance code, which I totally agree with, although
I couldn't think of a better way by that time. Then I got distracted with other things so
this was the last iteration.

But it can be an interesting starting point. I'm convinced this can be a great feature!
Think about all the user contexts we can define with uprobes for example.

Thanks.
--
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/