Messages in this thread |  | | Subject | Re: perf: prctl(PR_TASK_PERF_EVENTS_DISABLE) has no effect | From | Peter Zijlstra <> | Date | Mon, 30 Jan 2012 14:45:07 +0100 |
| |
On Mon, 2012-01-30 at 12:31 +0100, Ingo Molnar wrote: > * Peter Zijlstra <a.p.zijlstra@chello.nl> wrote: > > > On Mon, 2012-01-30 at 11:11 +0100, Ingo Molnar wrote: > > > So, what workflow are you suggesting to Andrew? > > > > Librarize perf record, then in your code do something like: > > > > #include "perf_record.h" > > Maybe. (and then it shouldnt be limited to perf_record.h but > should be events.h plus libevents.so or such)
Yes it should be, you want to reserve the more generic name for less narrow interfaces.
> > > > handle = perf_record_init(); /* creates perf events and creates > > a record thread that writes samples > > to perf.data, consumes env(PERF_*) > > for configuration, registers with > > at_exit() for cleanup */ > > if (!handle) > > /* burn */ > > > > /* do you other code */ > > > > perf_record_start(handle); > > > > /* do the bit you want profiled */ > > > > perf_record_stop(handle); > > > > Then build with -lperfrecord or so. Not too hard, right? > > Isnt a simple prctl() so much easier and faster?
I really don't want to add another two prctl()s for this, ideally I'd remove the ones we have now, but I've never done due to maintaining backwards blah..
> 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, 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.
|  |