Messages in this thread | | | Date | Wed, 28 May 2014 10:55:38 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH] perf: Differentiate exec() and non-exec() comm events |
| |
On Wed, May 28, 2014 at 11:45:04AM +0300, Adrian Hunter wrote: > perf tools like 'perf report' can aggregate samples by comm > strings, which generally works. However, there are other > potential use-cases. For example, to pair up 'calls' > with 'returns' accurately (from branch events like Intel BTS) > it is necessary to identify whether the process has exec'd. > Although a comm event is generated when an 'exec' happens > it is also generated whenever the comm string is changed > on a whim (e.g. by prctl PR_SET_NAME). This patch adds a > flag to the comm event to differentiate one case from the > other. > > In order to determine whether the kernel supports the new > flag, a selection bit named 'exec' is added to struct > perf_event_attr. The bit does nothing but will cause > perf_event_open() to fail if the bit is set on kernels > that do not have it defined. >
> --- a/include/uapi/linux/perf_event.h > +++ b/include/uapi/linux/perf_event.h > @@ -302,8 +302,8 @@ struct perf_event_attr { > exclude_callchain_kernel : 1, /* exclude kernel callchains */ > exclude_callchain_user : 1, /* exclude user callchains */ > mmap2 : 1, /* include mmap with inode data */ > - > - __reserved_1 : 40; > + exec : 1, /* flag comm events that are due to an exec */ > + __reserved_1 : 39; >
Yah.. that's just sad :-(
the only capabilities mask we have is in the mmap() page, so without mmap()ing we have no way to test that.
Would it make sense to call it comm_exec? [unhandled content-type:application/pgp-signature] | |