Re: perf: prctl(PR_TASK_PERF_EVENTS_DISABLE) has no effect

[Andi Kleen <andi@firstfloor.org>]

Ingo Molnar <mingo@kernel.org> writes:

> * Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
>
>> > It also allows system-wide profiling after you've modified a 
>> > library to self-profile, while your suggestion does not 
>> > allow that.
>> 
>> But its no long self-profiling when some other process is 
>> involved. And system wide is definitely not self.
>
> If I'm a library developer and want to self-profile my 
> modifications, then it's entirely appropriate to do a 
> system-wide profile to see the system-wide use of this library!
>
> System-wide and self-profiling is not exclusive. Think of it as 
> a narrow, precise filter applied to a given area of 
> functionality only.
>
> AFAICS the alternative, under your method, would be to recompile 
> every single app in the system - that's cumbersome beyond 
> imagination, I wouldn't even call it a solution, let alone a 
> quality implementation.
>
>> > > It really isn't that hard to make userspace do what is 
>> > > needed, it just takes a bit of work.
>> > 
>> > Even if your suggested solution was available (it isn't), my 
>> > suggested approach is easier to use and covers more 
>> > usecases.
>> > 
>> > User-space expecting the kernel to provide usable and 
>> > minimal interfaces is not 'being silly'. It's the 
>> > fundamental task of a kernel to provide them.
>> 
>> Bloating the interface for something that is already well 
>> possible is.
>
> There's no 'bloat' worth speaking off: a single bit out of an 
> already allocated bitmap, plus a single check in an already 
> existing loop, plus a single new command-line flag to the 
> tooling side and minimal glue.

I tried it some time ago because I had a user who was very interested in
getting rid of initialization overhead in measurements.
I have a little library too to self instrument, but it's 
still a lot more work than adding a ioctl or two.

The patch is actually broken (causes occasional crashes)
and does not implement the opt in bit (but that would be easy 
to add). And it's against a quite old kernel.

Also had to do the disabling only after exec to avoid some issues.

But it worked well enough for some tests.

There are likely better ways to implement this
(or least ways that don't crash :-)
Frederic's generic contexts also sound nice.

The nice thing is that combined with some LD_PRELOAD 
tricks you can even use it with unmodified binaries.

(not a submission or anything, just FYI)

-Andi

http://firstfloor.org/~andi/perf-disabled-1


-- 
ak@linux.intel.com -- Speaking for myself only