From: Frederic Weisbecker <fweisbec@gmail.com>
To: Ingo Molnar <mingo@kernel.org>, Jiri Olsa <jolsa@redhat.com>
Cc: Iegorov Oleg <oleg_iegorov@mentor.com>,
linux-perf-users@vger.kernel.org, mingo@elte.hu,
a.p.zijlstra@chello.nl, acme@ghostprotocols.net,
Arnaldo Carvalho de Melo <acme@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: [RFD] perf: events defined contexts (was Re: perf: prctl(PR_TASK_PERF_EVENTS_DISABLE) has no effect)
Date: Fri, 27 Jul 2012 13:56:36 +0200 [thread overview]
Message-ID: <20120727115633.GL1173@somewhere.redhat.com> (raw)
In-Reply-To: <20120727072647.GA3965@gmail.com>
On Fri, Jul 27, 2012 at 09:26:47AM +0200, Ingo Molnar wrote:
>
> * Iegorov Oleg <oleg_iegorov@mentor.com> wrote:
>
> > as there was no proposed solution that helped me in response to the
> > same post by Andrew Steets, I would like to know if it is possible
> > to disable/enable perf event counters from the source code?
> >
> > calling prctl(PR_TASK_PERF_EVENTS_DISABLE) has no effect, nor does
> > compiling with -fno-omit-frame-pointer option.
> >
> > It would be extremely useful to disable perf event counters for some
> > parts of code and re-enable them for other parts of code, like:
> >
> > prctl(PR_TASK_PERF_EVENTS_DISABLE);
> > // not important for performance analysis code
> > prctl(PR_TASK_PERF_EVENTS_ENABLE);
> > // code that needs to be analysed
> >
> > and then, run perf:
> >
> > $ perf record ./program
> > $ perf report
> >
> > Can anyone tell me how can I enable such functionality?
>
> So, the kernel bits to do this in a pretty quirky way are there,
> see:
>
> https://lkml.org/lkml/2012/1/30/99
>
> but the librarization bits are definitely non-obvious to do and
> it's no surprise that it has not been done yet.
>
> Regular 'perf record' in itself is not self-profiling - it's
> another task profiling you, so we cannot blanket allow
> PR_TASK_PERF_EVENTS_DISABLE to disable profiling.
>
> What we might want to do instead on the kernel side to offer the
> functionality you are asking for is to enable 'public/weak'
> events be created by the profiler on an opt-in basis, which can
> be turned off by child tasks as well via
> PR_TASK_PERF_EVENTS_DISABLE.
>
> On the profiling workflow side it would work in a very simple
> way, like this:
>
> perf record --self-profiling ./my-app
>
> In your app you stick in appropriately placed
> PR_TASK_PERF_EVENTS_DISABLE/ENABLE calls.
>
> On the technical side perf record creates events with that
> struct perf_event_attr::self_profiling flag set to 1. (the flag
> is disabled by default)
>
> The PR_TASK_PERF_EVENTS_DISABLE code in the modified kernel then
> iterates through all events and disables those that have this
> flag set, not just the ones owned by this task.
>
> Maybe someone on Cc: would be interested in implementing this
> new perf events feature?
The problem is more general than that I think.
We need to be able to define finer grained contexts than just
"task" and/or "CPU".
And reusing events themselves would be a nice interface.
For example create 3 events:
A = irq entry tracepoint
B = irq exit tracepoint
C = cpu-cycles
And say: I want to count cpu-cycles when event A fires and stop counting
when B fires.
With that you can count cpu cycles on irqs.
You could use any event you want to define your contexts: lock, functions, etc...
And even uprobes to define areas in userspace to profile. Would that solve
the initial problem in the thread? Like hook on function library entry/exit?
I talked about that to Jiri Olsa several times. May be he would be interested
in implementing this. I posted some patchets one year ago but got sidetracked.
This can give you an idea from where we can start: https://lkml.org/lkml/2011/3/14/346
Jiri, would you be interested in working on this?
next prev parent reply other threads:[~2012-07-27 11:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-26 10:54 perf: prctl(PR_TASK_PERF_EVENTS_DISABLE) has no effect Iegorov Oleg
2012-07-27 7:26 ` Ingo Molnar
2012-07-27 8:00 ` Peter Zijlstra
2012-07-27 8:18 ` Ingo Molnar
2012-07-27 8:29 ` Peter Zijlstra
2012-07-27 11:40 ` Iegorov Oleg
2012-07-27 11:53 ` Ingo Molnar
2012-07-30 20:04 ` Andi Kleen
2012-07-31 5:47 ` Peter Zijlstra
2012-07-31 7:16 ` Ingo Molnar
2012-07-31 19:48 ` Peter Zijlstra
2012-07-27 11:56 ` Frederic Weisbecker [this message]
2012-07-27 12:45 ` [RFD] perf: events defined contexts (was Re: perf: prctl(PR_TASK_PERF_EVENTS_DISABLE) has no effect) Jiri Olsa
2012-08-06 1:41 ` Namhyung Kim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120727115633.GL1173@somewhere.redhat.com \
--to=fweisbec@gmail.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@ghostprotocols.net \
--cc=acme@infradead.org \
--cc=jolsa@redhat.com \
--cc=linux-perf-users@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mingo@kernel.org \
--cc=oleg_iegorov@mentor.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).