From: Ingo Molnar <mingo@kernel.org>
To: Iegorov Oleg <oleg_iegorov@mentor.com>
Cc: linux-perf-users@vger.kernel.org, mingo@elte.hu,
a.p.zijlstra@chello.nl, acme@ghostprotocols.net,
"Frédéric Weisbecker" <fweisbec@gmail.com>,
"Arnaldo Carvalho de Melo" <acme@infradead.org>,
"Thomas Gleixner" <tglx@linutronix.de>
Subject: Re: perf: prctl(PR_TASK_PERF_EVENTS_DISABLE) has no effect
Date: Fri, 27 Jul 2012 09:26:47 +0200 [thread overview]
Message-ID: <20120727072647.GA3965@gmail.com> (raw)
In-Reply-To: <501121D3.3060700@mentor.com>
* 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?
Thanks,
Ingo
next prev parent reply other threads:[~2012-07-27 7:26 UTC|newest]
Thread overview: 31+ 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 [this message]
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 ` [RFD] perf: events defined contexts (was Re: perf: prctl(PR_TASK_PERF_EVENTS_DISABLE) has no effect) Frederic Weisbecker
2012-07-27 12:45 ` Jiri Olsa
2012-08-06 1:41 ` Namhyung Kim
-- strict thread matches above, loose matches on Subject: below --
2012-01-27 17:03 perf: prctl(PR_TASK_PERF_EVENTS_DISABLE) has no effect Andrew Steets
2012-01-27 17:12 ` Peter Zijlstra
2012-01-27 20:06 ` Andrew Steets
2012-01-27 21:34 ` Peter Zijlstra
2012-01-28 12:01 ` Ingo Molnar
2012-01-28 23:48 ` Andrew Steets
2012-01-29 16:32 ` Ingo Molnar
2012-01-29 17:50 ` Gleb Natapov
2012-01-30 9:52 ` Peter Zijlstra
2012-01-30 10:11 ` Ingo Molnar
2012-01-30 11:01 ` Peter Zijlstra
2012-01-30 11:31 ` Ingo Molnar
2012-01-30 13:45 ` Peter Zijlstra
2012-01-30 13:58 ` Ingo Molnar
2012-01-30 15:30 ` Arnaldo Carvalho de Melo
2012-01-30 15:29 ` Arnaldo Carvalho de Melo
2012-02-01 19:03 ` Frederic Weisbecker
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=20120727072647.GA3965@gmail.com \
--to=mingo@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@ghostprotocols.net \
--cc=acme@infradead.org \
--cc=fweisbec@gmail.com \
--cc=linux-perf-users@vger.kernel.org \
--cc=mingo@elte.hu \
--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).