Messages in this thread | | | Date | Thu, 24 Mar 2016 13:25:44 +0100 | From | Jiri Olsa <> | Subject | Re: [PATCH 2/5] ftrace perf: Move exclude_kernel tracepoint check to init event |
| |
On Thu, Mar 24, 2016 at 11:49:34AM +0100, Peter Zijlstra wrote: > On Thu, Mar 24, 2016 at 10:56:48AM +0100, Jiri Olsa wrote: > > On Wed, Mar 23, 2016 at 11:41:29AM +0100, Peter Zijlstra wrote: > > > On Wed, Mar 16, 2016 at 03:34:30PM +0100, Jiri Olsa wrote: > > > > We suppress events with attr::exclude_kernel set when > > > > the event is generated, so following capture will > > > > give no warning but won't produce any data: > > > > > > > > $ sudo perf record -e sched:sched_switch:u ls > > > > $ sudo /perf script | wc -l > > > > 0 > > > > > > > > Checking the attr::exclude_(kernel|user) at the event > > > > init time and failing right away for tracepoints from > > > > uprobes/kprobes and native ones: > > > > > > > > $ sudo perf record -e sched:sched_switch:u ls > > > > Error: > > > > The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (sched:sched_switch). > > > > /bin/dmesg may provide additional information. > > > > No CONFIG_PERF_EVENTS=y kernel support configured? > > > > Not sure about this one. The previous behaviour suggests > > > exclude_{user,kernel} is implemented, while the new behaviour says these > > > flags are not implemented, which is a functional regression. > > > > well I would not expect 'sched:sched_switch:u' to work (be implemented) > > > > and I thought it's better to trigger an error than silently 'produce' no data > > We're not in the business of protecting people from themselves are we? > And if you want to help them, do so in userspace.
yep, I planned to make user space patch to make that error more user friendly
> > And its not like the [uk] flags are hard to implement here.
sched:sched_switch:u ?
jirka
| |