Hello
I've been working on documenting the PERF_EVENT_IOC_SET_FILTER ioctl.
I've been trying for the past 2 days and have been unable to get any
result except EINVAL.
Does anyone ever use this ioctl? Does anyone know how to use this ioctl?
I understand it takes a pointer to a string that contains an
"ftrace_filter" but the ftrace documentation is very confusing and it's
unclear exactly what, if any, string is appropriate here. I've even
resorted to sprinkling printk()s throughout the parser code and still
can't figure out what's going on.
Vince
On 6/9/15 12:30 PM, Vince Weaver wrote:
> Hello
>
> I've been working on documenting the PERF_EVENT_IOC_SET_FILTER ioctl.
>
> I've been trying for the past 2 days and have been unable to get any
> result except EINVAL.
>
> Does anyone ever use this ioctl? Does anyone know how to use this ioctl?
yes and yes it works.
perf record -e irq:irq_handler_entry --filter irq==28 \
-e irq:softirq_entry --filter vec==6 -a \
-- sleep 5
On 6/9/15 1:51 PM, Vince Weaver wrote:
> # perf record -e irq:irq_handler_entry --filter irq==28 -e irq:softirq_entry --filter vec==6 -a -- sleep 5
> invalid or unsupported event: 'irq:irq_handler_entry'
> Run 'perf list' for a list of valid events
>
> perf list doesn't show any tracepoint events, despite having debugfs
> mounted and running as root and /sys/kernel/debug/tracing/events/ being
> populated.
Do you see this:
# ls /sys/kernel/debug/tracing/events/irq/irq_handler_entry/
enable filter format id trigger
It's used in kernel/irq/handle.c, handle_irq_event_percpu(). As I recall
this tracepoint has been around a long time.
David
On Tue, 9 Jun 2015, David Ahern wrote:
> On 6/9/15 12:30 PM, Vince Weaver wrote:
> > Hello
> >
> > I've been working on documenting the PERF_EVENT_IOC_SET_FILTER ioctl.
> >
> > I've been trying for the past 2 days and have been unable to get any
> > result except EINVAL.
> >
> > Does anyone ever use this ioctl? Does anyone know how to use this ioctl?
>
> yes and yes it works.
>
> perf record -e irq:irq_handler_entry --filter irq==28 \
> -e irq:softirq_entry --filter vec==6 -a \
> -- sleep 5
# perf record -e irq:irq_handler_entry --filter irq==28 -e irq:softirq_entry --filter vec==6 -a -- sleep 5
invalid or unsupported event: 'irq:irq_handler_entry'
Run 'perf list' for a list of valid events
perf list doesn't show any tracepoint events, despite having debugfs
mounted and running as root and /sys/kernel/debug/tracing/events/ being
populated.
Vince
On Tue, 9 Jun 2015 15:51:53 -0400 (EDT)
Vince Weaver <[email protected]> wrote:
> On Tue, 9 Jun 2015, David Ahern wrote:
>
> > On 6/9/15 12:30 PM, Vince Weaver wrote:
> > > Hello
> > >
> > > I've been working on documenting the PERF_EVENT_IOC_SET_FILTER ioctl.
> > >
> > > I've been trying for the past 2 days and have been unable to get any
> > > result except EINVAL.
> > >
> > > Does anyone ever use this ioctl? Does anyone know how to use this ioctl?
> >
> > yes and yes it works.
> >
> > perf record -e irq:irq_handler_entry --filter irq==28 \
> > -e irq:softirq_entry --filter vec==6 -a \
> > -- sleep 5
>
> # perf record -e irq:irq_handler_entry --filter irq==28 -e irq:softirq_entry --filter vec==6 -a -- sleep 5
> invalid or unsupported event: 'irq:irq_handler_entry'
> Run 'perf list' for a list of valid events
>
> perf list doesn't show any tracepoint events, despite having debugfs
> mounted and running as root and /sys/kernel/debug/tracing/events/ being
> populated.
>
What kernel are you using? You may need to update perf.
We switched to a tracefs filesystem, but the old perf wont read any
events if it's not located in debugfs. That is, it actually tested
which filesystem the event files were mounted on, and if they didn't
match the debugfs mount type, it ignored them. That was fixed recently.
-- Steve
On 6/9/15 2:02 PM, Vince Weaver wrote:
> # ls/sys/kernel/debug/tracing/events/irq/irq_handler_entry/
> enable filter format id trigger
>
> # perf list
> ....
> [ Tracepoints not available: No such file or directory ]
>
> strace shows
> statfs("/sys/kernel/debug/tracing/events", {f_type=0x74726163,
> f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0,
> f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
>
> so I have no idea what's going wrong here.
Check Steven's email; probably the issue.
>
>
> Anyway, on a related question, I see for the event that you use
> --filter irq==28
> How do I find out the valid filters for each event? Do I have to parse
> the "format" file under
> /sys/kernel/debug/tracing/events/*/* ?
Yes. And *very important* don't use the print fmt names, but the field
names. Often they are the same but when they differ it can be maddening.
On Tue, 9 Jun 2015, David Ahern wrote:
> On 6/9/15 1:51 PM, Vince Weaver wrote:
>
> > # perf record -e irq:irq_handler_entry --filter irq==28 -e
> > irq:softirq_entry --filter vec==6 -a -- sleep 5
> > invalid or unsupported event: 'irq:irq_handler_entry'
> > Run 'perf list' for a list of valid events
> >
> > perf list doesn't show any tracepoint events, despite having debugfs
> > mounted and running as root and /sys/kernel/debug/tracing/events/ being
> > populated.
>
> Do you see this:
>
> # ls /sys/kernel/debug/tracing/events/irq/irq_handler_entry/
> enable filter format id trigger
>
> It's used in kernel/irq/handle.c, handle_irq_event_percpu(). As I recall this
> tracepoint has been around a long time.
# ls /sys/kernel/debug/tracing/events/irq/irq_handler_entry/
enable filter format id trigger
# perf list
....
[ Tracepoints not available: No such file or directory ]
strace shows
statfs("/sys/kernel/debug/tracing/events", {f_type=0x74726163,
f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0,
f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
so I have no idea what's going wrong here.
Anyway, on a related question, I see for the event that you use
--filter irq==28
How do I find out the valid filters for each event? Do I have to parse
the "format" file under
/sys/kernel/debug/tracing/events/*/* ?
Vince
On Tue, 9 Jun 2015, Steven Rostedt wrote:
> What kernel are you using? You may need to update perf.
>
> We switched to a tracefs filesystem, but the old perf wont read any
> events if it's not located in debugfs. That is, it actually tested
> which filesystem the event files were mounted on, and if they didn't
> match the debugfs mount type, it ignored them. That was fixed recently.
I am running 4.1-rc7 and was trying to use perf_4.0.
If I use the kernel's version of perf it works.
sigh.
Vince
Em Tue, Jun 09, 2015 at 04:07:01PM -0400, Vince Weaver escreveu:
> On Tue, 9 Jun 2015, Steven Rostedt wrote:
>
> > What kernel are you using? You may need to update perf.
> >
> > We switched to a tracefs filesystem, but the old perf wont read any
> > events if it's not located in debugfs. That is, it actually tested
> > which filesystem the event files were mounted on, and if they didn't
> > match the debugfs mount type, it ignored them. That was fixed recently.
>
> I am running 4.1-rc7 and was trying to use perf_4.0.
>
> If I use the kernel's version of perf it works.
>
> sigh.
Indeed, its always a shame when that happens, I had a similar reaction
when Steven told it was validating the filesystem type, completely
unnecessary, has been there for a long time :-\
Date: Tue Jul 21 12:20:22 2009 -0400
perf_counter: Add tracepoint support to perf list, perf stat
- Arnaldo
On Tue, 9 Jun 2015, David Ahern wrote:
> On 6/9/15 2:02 PM, Vince Weaver wrote:
> > # ls/sys/kernel/debug/tracing/events/irq/irq_handler_entry/
> > enable filter format id trigger
> >
> > # perf list
> > ....
> > [ Tracepoints not available: No such file or directory ]
> >
> > strace shows
> > statfs("/sys/kernel/debug/tracing/events", {f_type=0x74726163,
> > f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0,
> > f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
> >
> > so I have no idea what's going wrong here.
>
> Check Steven's email; probably the issue.
>
> >
> >
> > Anyway, on a related question, I see for the event that you use
> > --filter irq==28
> > How do I find out the valid filters for each event? Do I have to parse
> > the "format" file under
> > /sys/kernel/debug/tracing/events/*/* ?
>
> Yes. And *very important* don't use the print fmt names, but the field names.
> Often they are the same but when they differ it can be maddening.
OK, thanks, this was very helpful, combined with figuring out the perf
issue, I finally have some code that is successfully using the ioctl.
The ftrace documentation says you can clear a filter by writing "0" to it,
but that doesn't seem to work with the ioctl.
Is there better documentation for the filters than the ftrace.txt file
that comes with the kernel?
Vince
* Steven Rostedt <[email protected]> wrote:
> On Tue, 9 Jun 2015 15:51:53 -0400 (EDT)
> Vince Weaver <[email protected]> wrote:
>
> > On Tue, 9 Jun 2015, David Ahern wrote:
> >
> > > On 6/9/15 12:30 PM, Vince Weaver wrote:
> > > > Hello
> > > >
> > > > I've been working on documenting the PERF_EVENT_IOC_SET_FILTER ioctl.
> > > >
> > > > I've been trying for the past 2 days and have been unable to get any
> > > > result except EINVAL.
> > > >
> > > > Does anyone ever use this ioctl? Does anyone know how to use this ioctl?
> > >
> > > yes and yes it works.
> > >
> > > perf record -e irq:irq_handler_entry --filter irq==28 \
> > > -e irq:softirq_entry --filter vec==6 -a \
> > > -- sleep 5
> >
> > # perf record -e irq:irq_handler_entry --filter irq==28 -e irq:softirq_entry --filter vec==6 -a -- sleep 5
> > invalid or unsupported event: 'irq:irq_handler_entry'
> > Run 'perf list' for a list of valid events
> >
> > perf list doesn't show any tracepoint events, despite having debugfs
> > mounted and running as root and /sys/kernel/debug/tracing/events/ being
> > populated.
> >
>
> What kernel are you using? You may need to update perf.
>
> We switched to a tracefs filesystem, but the old perf wont read any events if
> it's not located in debugfs. That is, it actually tested which filesystem the
> event files were mounted on, and if they didn't match the debugfs mount type, it
> ignored them. That was fixed recently.
That fix should probably be backported to stable kernels, to keep old instances
working.
Thanks,
Ingo