linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).