Re: perf: prctl(PR_TASK_PERF_EVENTS_DISABLE) has no effect

From: Ingo Molnar
Date: Mon Jan 30 2012 - 08:59:00 EST



* Peter Zijlstra <a.p.zijlstra@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/