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
