[PATCH V6 20/26] perf: changing pmu::setup_aux() parameter to include event

Mathieu Poirier mathieu.poirier at linaro.org
Fri Dec 11 13:58:57 PST 2015


On 11 December 2015 at 07:12, Alexander Shishkin
<alexander.shishkin at linux.intel.com> wrote:
> Mathieu Poirier <mathieu.poirier at linaro.org> writes:
>
>> For Coresight ETMv3/4 tracers the event carries information
>> about trace modes such as user or kernel space tracing and
>> whether tracing is allowed when operating in secure mode.
>
> Ok, so it looks to me that what you're doing in your setup_aux with the
> event, you should rather be doing in pmu::event_init(), which takes
> event as a parameter and it even makes more sense semantically, because
> that bit is really configuring the parameters of tracing and not
> capturing, which setup_aux() is more about. And the above paragraph also
> sounds very much like it. Since in Coresight there is a very clear
> distinction between trace generation (sources) and capturing (sinks) it
> should also be possible to structure the code in such a way that the
> former are not as closely tied to the latter. Please correct me if I'm
> missing something.

Conceptually there is no need to do the configuration for source, path
and sink in setup_aux() but all this information has to be kept
somewhere...  Since setup_aux() is where the private data structure
that will be used for the rest of the trace session gets created I
didn't see another way.

But with your patchset on trace filtering [1] I'm pretty sure we don't
need to do tracer configuration for all the tracers at the beginning.
I have to double check a few things but it is very likely that CS
tracer configuration can be made the same way PT is done, something
that will seriously simplify the setup process.

That leaves us with the path from source to sink - it is event
specific and as such needs to be part of the private data structure.
Unless you see a better way to proceed it will stay in setup_aux...

Thanks for the review,
Mathieu

[1]. https://lkml.org/lkml/2015/12/11/449

>
> Regards,
> --
> Alex



More information about the linux-arm-kernel mailing list