[PATCH] perf_event_open.2: 4.9 PERF_EVENT_IOC_SET_DRV_CONFIGS support

[PATCH] perf_event_open.2: 4.9 PERF_EVENT_IOC_SET_DRV_CONFIGS support

[Mathieu Poirier]

This manpage patch relates to the addition of the
PERF_EVENT_IOC_SET_DRV_CONFIGS ioctl.

link: http://www.spinics.net/lists/kernel/msg2318998.html
Signed-off-by: Mathieu Poirier <mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 man2/perf_event_open.2 | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/man2/perf_event_open.2 b/man2/perf_event_open.2
index 3c894ccd1209..315b6a91079a 100644
--- a/man2/perf_event_open.2
+++ b/man2/perf_event_open.2
@@ -2732,6 +2732,12 @@ The argument is a BPF program file descriptor that was created by
 a previous
 .BR bpf (2)
 system call.
+.TP
+.BR PERF_EVENT_IOC_SET_DRV_CONFIGS " (since Linux 4.9)"
+This makes it possible to pass configuration parameters to PMU drivers.
+Configuration parameters are specific to each drivers.
+
+The argument is a pointer to the desired configuration parameters.
 .SS Using prctl
 A process can enable or disable all the event groups that are
 attached to it using the
-- 
2.7.4

Re: [PATCH] perf_event_open.2: 4.9 PERF_EVENT_IOC_SET_DRV_CONFIGS support

[Vince Weaver]

On Thu, 11 Aug 2016, Mathieu Poirier wrote:

> This manpage patch relates to the addition of the
> PERF_EVENT_IOC_SET_DRV_CONFIGS ioctl.
> 
> link: http://www.spinics.net/lists/kernel/msg2318998.html
> Signed-off-by: Mathieu Poirier <mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>  man2/perf_event_open.2 | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/man2/perf_event_open.2 b/man2/perf_event_open.2
> index 3c894ccd1209..315b6a91079a 100644
> --- a/man2/perf_event_open.2
> +++ b/man2/perf_event_open.2
> @@ -2732,6 +2732,12 @@ The argument is a BPF program file descriptor that was created by
>  a previous
>  .BR bpf (2)
>  system call.
> +.TP
> +.BR PERF_EVENT_IOC_SET_DRV_CONFIGS " (since Linux 4.9)"
> +This makes it possible to pass configuration parameters to PMU drivers.
> +Configuration parameters are specific to each drivers.
> +
> +The argument is a pointer to the desired configuration parameters.
>  .SS Using prctl
>  A process can enable or disable all the event groups that are
>  attached to it using the

This is a bit... vague.  So we're adding an interface to allow passing 
arbitrary binary blobs through the perf_event interface?

Is there any structure at all to these blobs?  From the other commit 
messages it looked like you'd be passing in some sort of string.

Vince

Re: [PATCH] perf_event_open.2: 4.9 PERF_EVENT_IOC_SET_DRV_CONFIGS support

[Mathieu Poirier]

On 12 August 2016 at 10:52, Vince Weaver <vince-yfjdyHUqu3OsTnJN9+BGXg@public.gmane.org> wrote:
> On Thu, 11 Aug 2016, Mathieu Poirier wrote:
>
>> This manpage patch relates to the addition of the
>> PERF_EVENT_IOC_SET_DRV_CONFIGS ioctl.
>>
>> link: http://www.spinics.net/lists/kernel/msg2318998.html
>> Signed-off-by: Mathieu Poirier <mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> ---
>>  man2/perf_event_open.2 | 6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/man2/perf_event_open.2 b/man2/perf_event_open.2
>> index 3c894ccd1209..315b6a91079a 100644
>> --- a/man2/perf_event_open.2
>> +++ b/man2/perf_event_open.2
>> @@ -2732,6 +2732,12 @@ The argument is a BPF program file descriptor that was created by
>>  a previous
>>  .BR bpf (2)
>>  system call.
>> +.TP
>> +.BR PERF_EVENT_IOC_SET_DRV_CONFIGS " (since Linux 4.9)"
>> +This makes it possible to pass configuration parameters to PMU drivers.
>> +Configuration parameters are specific to each drivers.
>> +
>> +The argument is a pointer to the desired configuration parameters.
>>  .SS Using prctl
>>  A process can enable or disable all the event groups that are
>>  attached to it using the
>
> This is a bit... vague.  So we're adding an interface to allow passing
> arbitrary binary blobs through the perf_event interface?
>
> Is there any structure at all to these blobs?  From the other commit
> messages it looked like you'd be passing in some sort of string.

I am adding an interface to pass PMU specific configuration to the
driver.  Since PMU drivers exist for different architecture and
drivers I am making the mechanism as generic as possible.

In this case the CoreSight Tracers need to know what "sink" to use for
a trace session.  I've enhanced the perf cmd line tool to accept:

perf -e cs_etm/@sink=some_sink_definition/ ....

Everything falling with the '/' that is preceded by a '@' character is
considered PMU driver material.  At this time the perf lexer accept
two format:

"@cfg" and "@cfg=option".  The lexer will strip off the '@' and pass
"cfg" and "cfg=option" to the kernel.

What gets sent down to the kernel is driver specific - it is up to the
PMU drivers to parse and validate what's given to them.

This feature loosely mimics the filter enhancement where it is now
possible to specify:

perf record -e some_event// --filter 'start 0xstart_addr,stop 0xstop_address' or
perf record -e some_event// --filter 'filter 0xstart_address/offset'

Here it is up to the event to supply the mechanic to deal with the
filter specification (I'm doing the same thing).  Keywords "start",
"stop" and "filter" are common to both IntelPT and CoreSight tracers,
making them ideal candidates for parsing in the core.

But for driver specific configuration "sink" is only applicable to
CoreSight tracers...

Writing these lines I realise that "start", "stop" and "filter" are
applicable to only two drivers (IntelPT and CoreSight).  Peter, do you
think I should look for "sink" in the core parser, just like it is
done for filters?

Guidance would be appreciated here.

Mathieu

>
> Vince

Re: [PATCH] perf_event_open.2: 4.9 PERF_EVENT_IOC_SET_DRV_CONFIGS support

[Vince Weaver]

On Thu, 11 Aug 2016, Mathieu Poirier wrote:
> +.TP
> +.BR PERF_EVENT_IOC_SET_DRV_CONFIGS " (since Linux 4.9)"
> +This makes it possible to pass configuration parameters to PMU drivers.
> +Configuration parameters are specific to each drivers.
> +
> +The argument is a pointer to the desired configuration parameters.

So I gave up and read the code and I'm guessing this is what you really 
mean:

.TP
.BR PERF_EVENT_IOC_SET_DRV_CONFIGS " (since Linux 4.9)"
Pass custom configuration paramaters to a PMU driver.

The argument is a pointer to a NUL-termiated string of up to
PAGE_SIZE in length.
The string contains a list of comma-separated configuration options
that will be parsed by the kernel.
The kernel handles both singleton values as well as name/value pairs
that are indicated with the '=' character.
The size of the strings is limited internally to PERF_DRV_CONFIG_MAX
(which is not visible to userspace).



some additional questions: can this ioctl be run at any time or should it 
only be run while the event is quiet?  Does the change in options take
place immediately?

Vince
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] perf_event_open.2: 4.9 PERF_EVENT_IOC_SET_DRV_CONFIGS support

[Mathieu Poirier]

On 12 August 2016 at 11:57, Vince Weaver <vince-yfjdyHUqu3OsTnJN9+BGXg@public.gmane.org> wrote:
> On Thu, 11 Aug 2016, Mathieu Poirier wrote:
>> +.TP
>> +.BR PERF_EVENT_IOC_SET_DRV_CONFIGS " (since Linux 4.9)"
>> +This makes it possible to pass configuration parameters to PMU drivers.
>> +Configuration parameters are specific to each drivers.
>> +
>> +The argument is a pointer to the desired configuration parameters.
>
> So I gave up and read the code and I'm guessing this is what you really
> mean:
>
> .TP
> .BR PERF_EVENT_IOC_SET_DRV_CONFIGS " (since Linux 4.9)"
> Pass custom configuration paramaters to a PMU driver.
>
> The argument is a pointer to a NUL-termiated string of up to
> PAGE_SIZE in length.
> The string contains a list of comma-separated configuration options
> that will be parsed by the kernel.
> The kernel handles both singleton values as well as name/value pairs
> that are indicated with the '=' character.
> The size of the strings is limited internally to PERF_DRV_CONFIG_MAX
> (which is not visible to userspace).
>

Yes this is a very good description but in sharp contrast with what is
currently done for the ioctl() descriptors in this page.  I shied away
from writing that much based on how slim the current descriptions
were.

>
>
> some additional questions: can this ioctl be run at any time or should it
> only be run while the event is quiet?  Does the change in options take
> place immediately?

That is up to PMU drivers to decide - for CoreSight it is set only
once when trace sessions are created.  Any changes from thereon will
be ignored.

Thanks for the review.
Mathieu

>
> Vince
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] perf_event_open.2: 4.9 PERF_EVENT_IOC_SET_DRV_CONFIGS support

[Vince Weaver]

On Fri, 12 Aug 2016, Mathieu Poirier wrote:
> 
> I am adding an interface to pass PMU specific configuration to the
> driver.  Since PMU drivers exist for different architecture and
> drivers I am making the mechanism as generic as possible.

It's a shame we are ending up with two "string configuration" ioctls.
PERF_EVENT_IOC_SET_FILTER and this new one.  Though I guess
PERF_EVENT_IOC_SET_FILTER is not really set up to be used generically.

> "@cfg" and "@cfg=option".  The lexer will strip off the '@' and pass
> "cfg" and "cfg=option" to the kernel.
> 
> What gets sent down to the kernel is driver specific - it is up to the
> PMU drivers to parse and validate what's given to them.

But the core kernel is parsing "=" and "," in this case, so it's not 
entirely up to the PMU driver, right?

Is there going to be a list of allowed keywords somewhere, under /sys
or similar?

>> .TP
>> .BR PERF_EVENT_IOC_SET_DRV_CONFIGS " (since Linux 4.9)"
>> Pass custom configuration paramaters to a PMU driver.
>>
>> The argument is a pointer to a NUL-termiated string of up to
>> PAGE_SIZE in length.
>> The string contains a list of comma-separated configuration options
>> that will be parsed by the kernel.
>> The kernel handles both singleton values as well as name/value pairs
>> that are indicated with the '=' character.
>> The size of the strings is limited internally to PERF_DRV_CONFIG_MAX
>> (which is not visible to userspace).
>>

> Yes this is a very good description but in sharp contrast with what is
> currently done for the ioctl() descriptors in this page.  I shied away
> from writing that much based on how slim the current descriptions were.

Well that's because this interface is a lot more complex than some of the 
other ioctls which just take a simple integer (or no argument at all).

The ftrace ioctl description could definitely use some expansion.

> > some additional questions: can this ioctl be run at any time or should
> > only be run while the event is quiet?  Does the change in options take
> > place immediately?

> That is up to PMU drivers to decide - for CoreSight it is set only
> once when trace sessions are created.  Any changes from thereon will
> be ignored.

Then shouldn't this be set at perf_event_open() and not by an ioctl()?

Vince
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] perf_event_open.2: 4.9 PERF_EVENT_IOC_SET_DRV_CONFIGS support

[Mathieu Poirier]

On 12 August 2016 at 14:31, Vince Weaver <vince-yfjdyHUqu3OsTnJN9+BGXg@public.gmane.org> wrote:
> On Fri, 12 Aug 2016, Mathieu Poirier wrote:
>>
>> I am adding an interface to pass PMU specific configuration to the
>> driver.  Since PMU drivers exist for different architecture and
>> drivers I am making the mechanism as generic as possible.
>
> It's a shame we are ending up with two "string configuration" ioctls.
> PERF_EVENT_IOC_SET_FILTER and this new one.  Though I guess
> PERF_EVENT_IOC_SET_FILTER is not really set up to be used generically.
>
>> "@cfg" and "@cfg=option".  The lexer will strip off the '@' and pass
>> "cfg" and "cfg=option" to the kernel.
>>
>> What gets sent down to the kernel is driver specific - it is up to the
>> PMU drivers to parse and validate what's given to them.
>
> But the core kernel is parsing "=" and "," in this case, so it's not
> entirely up to the PMU driver, right?

Upon Peter's request the core will does some initial parsing but the
PMU drivers are responsible to parse the "cfg" and "option" parts in
order to validate their content.

>
> Is there going to be a list of allowed keywords somewhere, under /sys
> or similar?

SysFS is very constraining - I think it would be much better in the
PMU's documentation under Documentation/.  I have a patch ready for
that.

>
>>> .TP
>>> .BR PERF_EVENT_IOC_SET_DRV_CONFIGS " (since Linux 4.9)"
>>> Pass custom configuration paramaters to a PMU driver.
>>>
>>> The argument is a pointer to a NUL-termiated string of up to
>>> PAGE_SIZE in length.
>>> The string contains a list of comma-separated configuration options
>>> that will be parsed by the kernel.
>>> The kernel handles both singleton values as well as name/value pairs
>>> that are indicated with the '=' character.
>>> The size of the strings is limited internally to PERF_DRV_CONFIG_MAX
>>> (which is not visible to userspace).
>>>
>
>> Yes this is a very good description but in sharp contrast with what is
>> currently done for the ioctl() descriptors in this page.  I shied away
>> from writing that much based on how slim the current descriptions were.
>
> Well that's because this interface is a lot more complex than some of the
> other ioctls which just take a simple integer (or no argument at all).
>
> The ftrace ioctl description could definitely use some expansion.

I agree.

>
>> > some additional questions: can this ioctl be run at any time or should
>> > only be run while the event is quiet?  Does the change in options take
>> > place immediately?
>
>> That is up to PMU drivers to decide - for CoreSight it is set only
>> once when trace sessions are created.  Any changes from thereon will
>> be ignored.
>
> Then shouldn't this be set at perf_event_open() and not by an ioctl()?

Using an ioctl() seemed to be the best approach since all the
infrastructure is already there.  Also different drivers may need to
see configuration options updated - it is simply not the case for
CoreSight.

By the way, my next patchset will make PERF_DRV_CONFIG_MAX visible to
user space.

Thanks,
Mathieu

>
> Vince
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] perf_event_open.2: 4.9 PERF_EVENT_IOC_SET_DRV_CONFIGS support

[Michael Kerrisk (man-pages)]

Hi Mathieu,

This feature seems not to have made it into 4.9. (Or did I 
miss something?) Is it still planned for a future release?

Cheers,

Michael

On 08/12/2016 07:56 PM, Mathieu Poirier wrote:
> On 12 August 2016 at 10:52, Vince Weaver <vince-yfjdyHUqu3OsTnJN9+BGXg@public.gmane.org> wrote:
>> On Thu, 11 Aug 2016, Mathieu Poirier wrote:
>>
>>> This manpage patch relates to the addition of the
>>> PERF_EVENT_IOC_SET_DRV_CONFIGS ioctl.
>>>
>>> link: http://www.spinics.net/lists/kernel/msg2318998.html
>>> Signed-off-by: Mathieu Poirier <mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>> ---
>>>  man2/perf_event_open.2 | 6 ++++++
>>>  1 file changed, 6 insertions(+)
>>>
>>> diff --git a/man2/perf_event_open.2 b/man2/perf_event_open.2
>>> index 3c894ccd1209..315b6a91079a 100644
>>> --- a/man2/perf_event_open.2
>>> +++ b/man2/perf_event_open.2
>>> @@ -2732,6 +2732,12 @@ The argument is a BPF program file descriptor that was created by
>>>  a previous
>>>  .BR bpf (2)
>>>  system call.
>>> +.TP
>>> +.BR PERF_EVENT_IOC_SET_DRV_CONFIGS " (since Linux 4.9)"
>>> +This makes it possible to pass configuration parameters to PMU drivers.
>>> +Configuration parameters are specific to each drivers.
>>> +
>>> +The argument is a pointer to the desired configuration parameters.
>>>  .SS Using prctl
>>>  A process can enable or disable all the event groups that are
>>>  attached to it using the
>>
>> This is a bit... vague.  So we're adding an interface to allow passing
>> arbitrary binary blobs through the perf_event interface?
>>
>> Is there any structure at all to these blobs?  From the other commit
>> messages it looked like you'd be passing in some sort of string.
> 
> I am adding an interface to pass PMU specific configuration to the
> driver.  Since PMU drivers exist for different architecture and
> drivers I am making the mechanism as generic as possible.
> 
> In this case the CoreSight Tracers need to know what "sink" to use for
> a trace session.  I've enhanced the perf cmd line tool to accept:
> 
> perf -e cs_etm/@sink=some_sink_definition/ ....
> 
> Everything falling with the '/' that is preceded by a '@' character is
> considered PMU driver material.  At this time the perf lexer accept
> two format:
> 
> "@cfg" and "@cfg=option".  The lexer will strip off the '@' and pass
> "cfg" and "cfg=option" to the kernel.
> 
> What gets sent down to the kernel is driver specific - it is up to the
> PMU drivers to parse and validate what's given to them.
> 
> This feature loosely mimics the filter enhancement where it is now
> possible to specify:
> 
> perf record -e some_event// --filter 'start 0xstart_addr,stop 0xstop_address' or
> perf record -e some_event// --filter 'filter 0xstart_address/offset'
> 
> Here it is up to the event to supply the mechanic to deal with the
> filter specification (I'm doing the same thing).  Keywords "start",
> "stop" and "filter" are common to both IntelPT and CoreSight tracers,
> making them ideal candidates for parsing in the core.
> 
> But for driver specific configuration "sink" is only applicable to
> CoreSight tracers...
> 
> Writing these lines I realise that "start", "stop" and "filter" are
> applicable to only two drivers (IntelPT and CoreSight).  Peter, do you
> think I should look for "sink" in the core parser, just like it is
> done for filters?
> 
> Guidance would be appreciated here.
> 
> Mathieu
> 
>>
>> Vince
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: [PATCH] perf_event_open.2: 4.9 PERF_EVENT_IOC_SET_DRV_CONFIGS support

[Mathieu Poirier]

On 21 October 2016 at 00:50, Michael Kerrisk (man-pages)
<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi Mathieu,
>
> This feature seems not to have made it into 4.9. (Or did I
> miss something?) Is it still planned for a future release?

Good morning Michael,

We have decided to proceed differently and as such, it is no longer required.

Thanks for the follow-up,
Mathieu

>
> Cheers,
>
> Michael
>
> On 08/12/2016 07:56 PM, Mathieu Poirier wrote:
>> On 12 August 2016 at 10:52, Vince Weaver <vince-yfjdyHUqu3OsTnJN9+BGXg@public.gmane.org> wrote:
>>> On Thu, 11 Aug 2016, Mathieu Poirier wrote:
>>>
>>>> This manpage patch relates to the addition of the
>>>> PERF_EVENT_IOC_SET_DRV_CONFIGS ioctl.
>>>>
>>>> link: http://www.spinics.net/lists/kernel/msg2318998.html
>>>> Signed-off-by: Mathieu Poirier <mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>>> ---
>>>>  man2/perf_event_open.2 | 6 ++++++
>>>>  1 file changed, 6 insertions(+)
>>>>
>>>> diff --git a/man2/perf_event_open.2 b/man2/perf_event_open.2
>>>> index 3c894ccd1209..315b6a91079a 100644
>>>> --- a/man2/perf_event_open.2
>>>> +++ b/man2/perf_event_open.2
>>>> @@ -2732,6 +2732,12 @@ The argument is a BPF program file descriptor that was created by
>>>>  a previous
>>>>  .BR bpf (2)
>>>>  system call.
>>>> +.TP
>>>> +.BR PERF_EVENT_IOC_SET_DRV_CONFIGS " (since Linux 4.9)"
>>>> +This makes it possible to pass configuration parameters to PMU drivers.
>>>> +Configuration parameters are specific to each drivers.
>>>> +
>>>> +The argument is a pointer to the desired configuration parameters.
>>>>  .SS Using prctl
>>>>  A process can enable or disable all the event groups that are
>>>>  attached to it using the
>>>
>>> This is a bit... vague.  So we're adding an interface to allow passing
>>> arbitrary binary blobs through the perf_event interface?
>>>
>>> Is there any structure at all to these blobs?  From the other commit
>>> messages it looked like you'd be passing in some sort of string.
>>
>> I am adding an interface to pass PMU specific configuration to the
>> driver.  Since PMU drivers exist for different architecture and
>> drivers I am making the mechanism as generic as possible.
>>
>> In this case the CoreSight Tracers need to know what "sink" to use for
>> a trace session.  I've enhanced the perf cmd line tool to accept:
>>
>> perf -e cs_etm/@sink=some_sink_definition/ ....
>>
>> Everything falling with the '/' that is preceded by a '@' character is
>> considered PMU driver material.  At this time the perf lexer accept
>> two format:
>>
>> "@cfg" and "@cfg=option".  The lexer will strip off the '@' and pass
>> "cfg" and "cfg=option" to the kernel.
>>
>> What gets sent down to the kernel is driver specific - it is up to the
>> PMU drivers to parse and validate what's given to them.
>>
>> This feature loosely mimics the filter enhancement where it is now
>> possible to specify:
>>
>> perf record -e some_event// --filter 'start 0xstart_addr,stop 0xstop_address' or
>> perf record -e some_event// --filter 'filter 0xstart_address/offset'
>>
>> Here it is up to the event to supply the mechanic to deal with the
>> filter specification (I'm doing the same thing).  Keywords "start",
>> "stop" and "filter" are common to both IntelPT and CoreSight tracers,
>> making them ideal candidates for parsing in the core.
>>
>> But for driver specific configuration "sink" is only applicable to
>> CoreSight tracers...
>>
>> Writing these lines I realise that "start", "stop" and "filter" are
>> applicable to only two drivers (IntelPT and CoreSight).  Peter, do you
>> think I should look for "sink" in the core parser, just like it is
>> done for filters?
>>
>> Guidance would be appreciated here.
>>
>> Mathieu
>>
>>>
>>> Vince
>>
>
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html