[lkml]   [2012]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: perf: prctl(PR_TASK_PERF_EVENTS_DISABLE) has no effect

* Peter Zijlstra <> wrote:

> > What's your concern with the prctl()? This would arguably be
> > the right kind of usage for prctl(): it's an established
> > API/ABI for process/task-wide settings.
> Its doing things backwards, [...]

What does that mean?

> [...] also the whole concept of allowing people to hide things
> from a profiler is so rotten I'm not willing to even consider
> the notion.

But what we want here is not to hide things from the profiler,
what we want to be able to is to *ask* the profiler to hide
things for us, and we do that for a good reason.

This distinction (which I agree is important) could be
implemented by adding a "allow self-profiling" bit (default
disabled) in the perf_attr. That way such code would not be able
to 'hide' from a simple:

perf top
perf record -a

session, but would be able to self-profile from such a session:

perf record --allow-self-profile ...

where there could be some easy shortcut for
--allow-self-profile, such as:

perf record -S

that way no code could ever hide from a profiler, only if the
profiler is specifically allowing self-profiling. (opt in)

The librarization you suggested might make sense too - but i
think people will gravitate towards the easier to use variant,
and prctl() is as easy and straightforward as it gets.

We can Cc: it to Linus with an explicit [RFC] and he can shoot
it down if the API is ugly - but I don't think it's ugly.




 \ /
  Last update: 2012-01-30 15:01    [W:0.044 / U:34.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site