All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.