Messages in this thread | | | Date | Mon, 30 Jan 2012 14:58:36 +0100 | From | Ingo Molnar <> | Subject | Re: perf: prctl(PR_TASK_PERF_EVENTS_DISABLE) has no effect |
| |
* Peter Zijlstra <a.p.zijlstra@chello.nl> 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.
Hm?
Thanks,
Ingo
| |