[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160324095648.GC8893@krava.brq.redhat.com>
Date: Thu, 24 Mar 2016 10:56:48 +0100
From: Jiri Olsa <jolsa@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Jiri Olsa <jolsa@...nel.org>, Steven Rostedt <rostedt@...dmis.org>,
lkml <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>,
Namhyung Kim <namhyung@...nel.org>,
Arnaldo Carvalho de Melo <acme@...nel.org>
Subject: Re: [PATCH 2/5] ftrace perf: Move exclude_kernel tracepoint check to
init event
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?
> >
> > $ sudo perf record -e probe:sys_read:u ls
> > Error:
> > The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (probe:sys_read).
> > /bin/dmesg may provide additional information.
> > No CONFIG_PERF_EVENTS=y kernel support configured?
> >
> > $ ./perf record -e probe_ex:main:k ./ex
> > Error:
> > The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (probe_ex:main).
> > /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
>
> That is, if all events are from kernel space, and we exclude all kernel
> events, 0 is the right answer not an error.
>
> Sure, with uprobes the situation is currently broken, but this isn't a
> fix.
Powered by blists - more mailing lists