Re: [PATCH v0 0/5] perf: Introduce instruction trace filtering

[Mathieu Poirier]

On 14 December 2015 at 01:50, Alexander Shishkin
<alexander.shishkin@xxxxxxxxxxxxxxx> wrote:
> Mathieu Poirier <mathieu.poirier@xxxxxxxxxx> writes:
>
>> On 11 December 2015 at 06:36, Alexander Shishkin
>> <alexander.shishkin@xxxxxxxxxxxxxxx> wrote:
>> Alex, Peter and al,
>>
>> As I mentioned in a previous reply I think this patchset is aiming in
>> the right direction.  Here we are dealing with address range
>> filtering, something that is common to both IntelPT and CS, but what
>> happens when we want introduce options that aren't generic to all
>> tracers and still want to us the ioctl method?
>
> Are we still talking about filtering options or more like event
> configuration? First, we need to understand if one particular feature or
> an option should be enabled for the entire lifetime of an event or if it
> should be configurable on the fly. For the former, you can use
> attr.config and friends, for the latter it makes sense to use an ioctl.
> If we're still talking about address range filtering, there is one
> difference in coresight that I'm aware of, which is specifying
> individual addresses as start/stop triggers (as opposed to enable
> ranges) and that is already taken care of in the current parser, I
> should probably write a comment to make it more apparent.

Yes, I saw that option.

>
> So my approach was to not consider them to be architecture specific
> features, but simply features that either are or aren't supported by a
> particular pmu.
>
>> Can we make the current scheme more extensible or generic so that
>> adding more architecture specific option is easily feasible?
>
> Well, the bigger question is, how do you represent a very architecture
> specific option in the core structures. I have one solution to that that
> is described above. It shouldn't take much architecture-specific code to
> handle each new option, unless it something that really only makes sense
> for one architecture/pmu.
>
> All that said, one could still extend the current code quite easily to
> fit completely non-generic things. In the default clause, in the parser
> function, one could add:
>
>   if (state == IF_STATE_ACTION)
>       if (event->pmu->itrace_filter_parse(event, &filter))
>           goto fail;
>
> if one really had to.

What I had in mind is more advanced tracing features like state
machines and counters but in hindsight I have no plans to play with
those any time soon.

What's more pressing is the need to be able to select the sink that
will gather the trace data from the perf cmd line tool.  At this time
it is a two step process that needs to be fixed.  At first I was
thinking about something like:

perf record -e cs_etm/sink:XYZ.tmc/

But from what I gathered it won't be easily feasible without changing
a lot of things - I think your ioctl() mechanism is much better for
something like that.  And sink selection a one time thing that doesn't
change throughout the trace session.

Based on what I found on the internet one would use ioctl() like this:

perf record -e intel_pt// --filter kernel:0x80000/0x1000

As such and thinking along the same lines I could fix my sink
enablement problem like this:

perf record -e intel_pt// --filter sink:XYZ.tmc

But a sink isn't a filter.  Maybe using the PERF_EVENT_IOC_SET_OUTPUT
would be a better choice but then again, a sink isn't a file.  So I'm
a little puzzled here.  Maybe Peter or Arnaldo would be able to advise
here...

Long story short my request to make things more generic can be put to rest.

Thanks,
Mathieu

>
>
> Regards,
> --
> Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/