From: James Clark <james.clark@arm.com>
To: Anshuman Khandual <anshuman.khandual@arm.com>,
acme@kernel.org, linux-perf-users@vger.kernel.org
Cc: german.gomez@arm.com, leo.yan@linaro.com,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/4] perf script: Output branch sample type
Date: Tue, 8 Mar 2022 12:09:31 +0000 [thread overview]
Message-ID: <937810c4-a752-18ec-523d-fc4c9f2d75c7@arm.com> (raw)
In-Reply-To: <3b6007ef-1ad8-c495-26aa-7974af8faefa@arm.com>
On 08/03/2022 05:22, Anshuman Khandual wrote:
>
>
> On 3/7/22 22:49, James Clark wrote:
>> The type info is saved when using '-j save_type'. Output this in perf
>
> Mentioning PERF_SAMPLE_BRANCH_CALL_STACK here as well might be better.
>
>> script so it can be accessed by other tools or for debugging.
>>
>> It's appended to the end of the list of fields so any existing tools
>> that split on / and access fields via an index are not affected. Also
>> output '-' instead of 'N/A' when the branch type isn't saved because /
>> is used as a field separator.
>
> Did not get it. Why 'N/A' should have been used anyway ?
N/A would be printed if branch type isn't saved because then branch type == 0.
N/A is the name that's assigned to the 0 entry of the branch type name list.
>
>>
>> Entries before this change look like this:
>>
>> 0xaaaadb350838/0xaaaadb3507a4/P/-/-/0
>>
>> And afterwards like this:
>>
>> 0xaaaadb350838/0xaaaadb3507a4/P/-/-/0/CALL
>>
>> or this if no type info is saved:
>>
>> 0x7fb57586df6b/0x7fb5758731f0/P/-/-/143/-
>
> 143 ?
Just random output from my laptop probably. It's not supposed to match up
with the previous entries, it's a new run and a new set of output.
>
>>
>> Signed-off-by: James Clark <james.clark@arm.com>
>> ---
>> tools/perf/builtin-script.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
>> index fac2e9470926..5e4a262a6825 100644
>> --- a/tools/perf/builtin-script.c
>> +++ b/tools/perf/builtin-script.c
>> @@ -859,11 +859,12 @@ mispred_str(struct branch_entry *br)
>>
>> static int print_bstack_flags(FILE *fp, struct branch_entry *br)
>> {
>> - return fprintf(fp, "/%c/%c/%c/%d ",
>> + return fprintf(fp, "/%c/%c/%c/%d/%s ",
>> mispred_str(br),
>> br->flags.in_tx ? 'X' : '-',
>> br->flags.abort ? 'A' : '-',
>> - br->flags.cycles);
>> + br->flags.cycles,
>> + br->flags.type ? branch_type_name(br->flags.type) : "-");
>> }
>>
>> static int perf_sample__fprintf_brstack(struct perf_sample *sample,
>
>
> LGTM but as mentioned before, I hope this does not affect any existing
> parsing tools.
It's possible for this perf script change. But any parser would have to be splitting on
/ and spaces and indexing into the result so I can't see how it's possible to make a parser
that wouldn't handle an entry appended to the end.
I imagine someone could have an assert that checks the number of results after the split on /.
But if they added that I'm assuming they were thinking of the possibility that extra entries
could be added so handle it properly.
next prev parent reply other threads:[~2022-03-08 12:09 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-07 17:19 [PATCH 0/4] Branch stack improvements James Clark
2022-03-07 17:19 ` [PATCH 1/4] perf: Add error message for unsupported branch stack cases James Clark
2022-03-08 4:17 ` Anshuman Khandual
2022-03-07 17:19 ` [PATCH 2/4] perf: Print branch stack entry type in --dump-raw-trace James Clark
2022-03-08 4:29 ` Anshuman Khandual
2022-03-08 11:58 ` James Clark
2022-03-07 17:19 ` [PATCH 3/4] perf: Refactor perf script branch stack printing James Clark
2022-03-08 5:06 ` Anshuman Khandual
2022-03-07 17:19 ` [PATCH 4/4] perf script: Output branch sample type James Clark
2022-03-08 5:22 ` Anshuman Khandual
2022-03-08 12:09 ` James Clark [this message]
2022-03-07 17:53 ` [PATCH 0/4] Branch stack improvements Arnaldo Carvalho de Melo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=937810c4-a752-18ec-523d-fc4c9f2d75c7@arm.com \
--to=james.clark@arm.com \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=anshuman.khandual@arm.com \
--cc=german.gomez@arm.com \
--cc=jolsa@kernel.org \
--cc=leo.yan@linaro.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=namhyung@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).