All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Liang, Kan" <kan.liang@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>,
	Stephane Eranian <eranian@google.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>,
	Ingo Molnar <mingo@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>, Jiri Olsa <jolsa@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	vitaly.slobodskoy@intel.com, pavel.gerasimov@intel.com,
	Andi Kleen <ak@linux.intel.com>,
	Michael Ellerman <mpe@ellerman.id.au>
Subject: Re: [PATCH V4 03/13] perf tools: Support new branch sample type for LBR TOS
Date: Tue, 19 Nov 2019 17:17:12 -0500	[thread overview]
Message-ID: <91cf3b08-c0ec-9bcd-669e-c5c91bda71ce@linux.intel.com> (raw)
In-Reply-To: <20191119213124.GO3079@worktop.programming.kicks-ass.net>



On 11/19/2019 4:31 PM, Peter Zijlstra wrote:
> On Tue, Nov 19, 2019 at 11:00:00AM -0800, Stephane Eranian wrote:
>> On Tue, Nov 19, 2019 at 6:35 AM <kan.liang@linux.intel.com> wrote:
> 
>>> diff --git a/tools/include/uapi/linux/perf_event.h b/tools/include/uapi/linux/perf_event.h
>>> index bb7b271397a6..c2da61c9ace7 100644
>>> --- a/tools/include/uapi/linux/perf_event.h
>>> +++ b/tools/include/uapi/linux/perf_event.h
>>> @@ -180,7 +180,10 @@ enum perf_branch_sample_type_shift {
>>>
>>>          PERF_SAMPLE_BRANCH_TYPE_SAVE_SHIFT      = 16, /* save branch type */
>>>
>>> -       PERF_SAMPLE_BRANCH_MAX_SHIFT            /* non-ABI */
>>> +       PERF_SAMPLE_BRANCH_MAX_SHIFT            = 17, /* non-ABI */
>>> +
>>> +       /* PMU specific */
>>
>> No! You must abstract this.
>>
>>> +       PERF_SAMPLE_BRANCH_LBR_TOS_SHIFT        = 63, /* save LBR TOS */
>>>   };
>>>
>> I don't like this because this is too Intel specific.
>> What is the meaning of this field? You need a clear definition so it can be used
>> with other PERF_SAMPLE_BRANCH_* implementations.
> 
> I also detest the MSB usage. Normal pattern is that any bit >= MAX
> will be rejected by the kernel.
>

OK. I will still use bit 17 for the new branch sample type.

I can change the Intel specific name, and use a generic name. How about 
PERF_SAMPLE_BRANCH_PMU_SPECIFIC?

If we make it generic, there will be another question. How much space 
should we reserve for this new branch sample type?
For LBR TOS, we only need a u64.
I'm not sure if it's good enough for other platforms.

Or maybe we want a flexible space as below?
@@ -849,7 +854,12 @@ 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_PMU_SPECIFIC is set
+        *        u64                   nr;
+        *        u64                   data[nr];
+        *      } && PERF_SAMPLE_BRANCH_STACK
          *
          *      { u64                   abi; # enum perf_sample_regs_abi
          *        u64                   regs[weight(mask)]; } && 
PERF_SAMPLE_REGS_USER


Thanks,
Kan


  reply	other threads:[~2019-11-19 22:17 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-19 14:33 [PATCH V4 00/13] Stitch LBR call stack kan.liang
2019-11-19 14:33 ` [PATCH V4 01/13] perf/core: Add new branch sample type for LBR TOS kan.liang
2019-11-19 19:02   ` Stephane Eranian
2019-11-19 22:25     ` Liang, Kan
2019-11-19 22:51       ` Stephane Eranian
2019-11-20 15:06         ` Liang, Kan
2019-11-19 14:34 ` [PATCH V4 02/13] perf/x86/intel: Output LBR TOS information kan.liang
2019-11-19 14:34 ` [PATCH V4 03/13] perf tools: Support new branch sample type for LBR TOS kan.liang
2019-11-19 19:00   ` Stephane Eranian
2019-11-19 21:31     ` Peter Zijlstra
2019-11-19 22:17       ` Liang, Kan [this message]
2019-11-19 14:34 ` [PATCH V4 04/13] perf header: Add check for event attr kan.liang
2019-11-19 14:34 ` [PATCH V4 05/13] perf pmu: Add support for PMU capabilities kan.liang
2019-11-19 14:34 ` [PATCH V4 06/13] perf header: Support CPU " kan.liang
2019-11-19 14:34 ` [PATCH V4 07/13] perf machine: Refine the function for LBR call stack reconstruction kan.liang
2019-11-19 14:34 ` [PATCH V4 08/13] perf tools: Stitch LBR call stack kan.liang
2019-11-19 14:34 ` [PATCH V4 09/13] perf report: Add option to enable the LBR stitching approach kan.liang
2019-11-19 14:34 ` [PATCH V4 10/13] perf script: " kan.liang
2019-11-19 14:34 ` [PATCH V4 11/13] perf top: " kan.liang
2019-11-19 14:34 ` [PATCH V4 12/13] perf c2c: " kan.liang
2019-11-19 14:34 ` [RFC PATCH V4 13/13] perf hist: Add fast path for duplicate entries check approach 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=91cf3b08-c0ec-9bcd-669e-c5c91bda71ce@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.