lkml.org 
[lkml]   [2021]   [Feb]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 7/7] Documentation: coresight: Add PID tracing description
On Thu, Feb 04, 2021 at 12:14:12PM +0000, Mike Leach wrote:

[...]

> > >>> +To support tracing PID for the kernel runs at different exception levels,
> > >>> +the PMU formats are defined as follow:
> > >>> +
> > >>> + "contextid1": Available on both EL1 kernel and EL2 kernel. When the
> > >>> + kernel is running at EL1, "contextid1" enables the PID
> > >>> + tracing; when the kernel is running at EL2, this enables
> > >>> + tracing the PID of guest applications.
> > >>> +
> > >>> + "contextid2": Only usable when the kernel is running at EL2. When
> > >>> + selected, enables PID tracing on EL2 kernel.
> > >>> +
> > >>> + "contextid": Will be an alias for the option that enables PID
> > >>> + tracing. I.e,
> > >>> + contextid == contextid1, on EL1 kernel.
> > >>> + contextid == contextid2, on EL2 kernel.
> > >>> +
> > >>> +The perf tool automatically sets corresponding bit for the "contextid" config,
> > >>> +therefore, the user doesn't have to bother which EL the kernel is running.
> > >>> +
> > >>> + i.e, perf record -e cs_etm/contextid/u -- uname
> > >>> + or perf record -e cs_etm//u -- uname
> > >>> +
> > >>> +will always do the "PID" tracing, independent of the kernel EL.
> > >>> +
> > >>
> > >> This is telling me that both cs_etm// and cs_etm/contextid/ have the
> > >> same effect - trace PID. Is this correct?
> > >
> >
> > Just to make this clear, this is not a side effect of the patch.
>
> Which is fine - but the documentation should accurately reflect what
> is happening on the system.
> This is a new paragraph about the PID tracing or otherwise, Even if
> some of the effects pre-date this patch, they have to be accurately
> communicated.
> I am also reading the new paragraph in the context of the rest of the
> coresight.rst document - which is a user level document explaining the
> basic operation of the coresight system and tools.
> This document mentions no other perf command line parameters relevant
> to coresight other than the @sink option.It actually calls out to the
> OpenCSD docs to provide further information.
>
> > The perf
> > tool driver automatically adds the "contextid" tracing and timestamp for
> > "system wide" and process bound events, as they traces get mixed into
> > the single sink. So these options are added implicitly by the perf tool
> > to make the decoding easier.
> >
>
> That's fine - I have no problem with contextID trace enabled by
> default. Context ID is relatively low overhead - and only emitted at
> start of trace / context changes.
> But the explanation of the parameters currently reads as though they
> always have an effect - and not putting them in there will omit the
> effect - unless you spot the very subtle line at the end.
>
> The user does not need to know about parameters that have no effect!

Thanks for the suggestion, Mike.

> Perhaps a better approach would be to explain the above - an explicit
> statement that "perf will always enable PID/ contextID tracing at the
> relevant EL - but for EL2 it is possible to make specific adjustments
> using parameters......."

Usually users assume the PMU format has no effect if without set it; but
this is not the case for the config "contextid", this config has been
automatically enabled by perf tool.

Based on your suggesiton, will refine the descrption for two things:
clarify what's the common usage for EL1/EL2, and what's specific for
EL2.

Thanks,
Leo

\
 
 \ /
  Last update: 2021-02-05 06:44    [W:0.109 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site