From: "Liang, Kan" <kan.liang@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: eranian@google.com, acme@redhat.com, mingo@kernel.org,
mpe@ellerman.id.au, linux-kernel@vger.kernel.org,
jolsa@kernel.org, namhyung@kernel.org,
vitaly.slobodskoy@intel.com, pavel.gerasimov@intel.com,
ak@linux.intel.com
Subject: Re: [RESEND PATCH V5 1/2] perf/core: Add new branch sample type for HW index of raw branch records
Date: Mon, 20 Jan 2020 15:47:22 -0500 [thread overview]
Message-ID: <71ead9fd-04db-e859-2842-3eddc77c35c4@linux.intel.com> (raw)
In-Reply-To: <20200120202445.GD14914@hirez.programming.kicks-ass.net>
On 1/20/2020 3:24 PM, Peter Zijlstra wrote:
> On Mon, Jan 20, 2020 at 11:50:59AM -0500, Liang, Kan wrote:
>>
>>
>> On 1/20/2020 4:23 AM, Peter Zijlstra wrote:
>>> On Thu, Jan 16, 2020 at 07:57:56AM -0800, kan.liang@linux.intel.com wrote:
>>>
>>>> struct perf_branch_stack {
>>>> __u64 nr;
>>>> + __u64 hw_idx;
>>>> struct perf_branch_entry entries[0];
>>>> };
>>>
>>> The above and below order doesn't match.
>>>
>>>> @@ -849,7 +853,11 @@ enum perf_event_type {
>>>> * char data[size];}&& PERF_SAMPLE_RAW
>>>> *
>>>> * { u64 nr;
>>>> - * { u64 from, to, flags } lbr[nr];} && PERF_SAMPLE_BRANCH_STACK
>>>> + * { u64 from, to, flags } lbr[nr];
>>>> + *
>>>> + * # only available if PERF_SAMPLE_BRANCH_HW_INDEX is set
>>>> + * u64 hw_idx;
>>>> + * } && PERF_SAMPLE_BRANCH_STACK
>>>
>>> That wants to be written as:
>>>
>>> { u64 nr;
>>> { u64 from, to, flags; } entries[nr];
>>> { u64 hw_idx; } && PERF_SAMPLE_BRANCH_HW_INDEX
>>> } && PERF_SAMPLE_BRANCH_STACK
>>>
>>> But the big question is; why isn't it:
>>>
>>> { u64 nr;
>>> { u64 hw_idx; } && PERF_SAMPLE_BRANCH_HW_INDEX
>>> { u64 from, to, flags; } entries[nr];
>>> } && PERF_SAMPLE_BRANCH_STACK
>>>
>>> to match the struct perf_branch_stack order. Having that variable sized
>>> entry in the middle just seems weird.
>>
>>
>> Usually, new data should be output to the end of a sample.
>
> Because.... you want old tools to read new output?
>
Yes, for some cases, it helps.
If no other sample types are output after PERF_SAMPLE_BRANCH_STACK,
old perf tool will ignore the hw_idx.
But, if we also have to output other sample types, e.g
PERF_SAMPLE_DATA_SRC or PERF_SAMPLE_PHYS_ADDR, which are output after
PERF_SAMPLE_BRANCH_STACK. The hw_idx will mess them up.
Old perf tool doesn't work anymore.
>> However, the entries[0] is sized entry, so I have to put the hw_idx before
>
> entries[0] is only in the C thing, and in C you indeed have to put
> hw_idx before.
>
>> entry. It makes the inconsistency. Sorry for the confusion caused.
>
> n/p it's clear now I think.
Should I send V6 patch to move hw_idx before entry as below?
@@ -853,7 +857,9 @@ enum perf_event_type {
* char data[size];}&& PERF_SAMPLE_RAW
*
* { u64 nr;
- * { u64 from, to, flags } lbr[nr];} &&
PERF_SAMPLE_BRANCH_STACK
+ * { u64 hw_idx; } && PERF_SAMPLE_BRANCH_HW_INDEX
+ * { u64 from, to, flags } lbr[nr];
+ * } && PERF_SAMPLE_BRANCH_STACK
*
* { u64 abi; # enum perf_sample_regs_abi
* u64 regs[weight(mask)]; } &&
PERF_SAMPLE_REGS_USER
@@ -6634,6 +6639,8 @@ void perf_output_sample(struct perf_output_handle
*handle,
* sizeof(struct perf_branch_entry);
perf_output_put(handle, data->br_stack->nr);
+ if (perf_sample_save_hw_index(event))
+ perf_output_put(handle,
data->br_stack->hw_idx);
perf_output_copy(handle,
data->br_stack->entries, size);
} else {
/*
Thanks,
Kan
next prev parent reply other threads:[~2020-01-20 20:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-16 15:57 [RESEND PATCH V5 0/2] Stitch LBR call stack (kernel) kan.liang
2020-01-16 15:57 ` [RESEND PATCH V5 1/2] perf/core: Add new branch sample type for HW index of raw branch records kan.liang
2020-01-20 9:23 ` Peter Zijlstra
2020-01-20 16:50 ` Liang, Kan
2020-01-20 20:24 ` Peter Zijlstra
2020-01-20 20:47 ` Liang, Kan [this message]
2020-01-21 9:32 ` Stephane Eranian
2020-01-21 15:02 ` Liang, Kan
2020-01-16 15:57 ` [RESEND PATCH V5 2/2] perf/x86/intel: Output LBR TOS information kan.liang
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=71ead9fd-04db-e859-2842-3eddc77c35c4@linux.intel.com \
--to=kan.liang@linux.intel.com \
--cc=acme@redhat.com \
--cc=ak@linux.intel.com \
--cc=eranian@google.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=namhyung@kernel.org \
--cc=pavel.gerasimov@intel.com \
--cc=peterz@infradead.org \
--cc=vitaly.slobodskoy@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.