All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Liang, Kan" <kan.liang@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>,
	Michael Ellerman <mpe@ellerman.id.au>
Cc: acme@kernel.org, mingo@kernel.org, linux-kernel@vger.kernel.org,
	jolsa@kernel.org, namhyung@kernel.org,
	vitaly.slobodskoy@intel.com, pavel.gerasimov@intel.com,
	ak@linux.intel.com, eranian@google.com
Subject: Re: [PATCH V3 01/13] perf/core: Add new branch sample type for LBR TOS
Date: Thu, 24 Oct 2019 11:50:07 -0400	[thread overview]
Message-ID: <2acd43e0-0b78-44e5-7b4e-b87c251db284@linux.intel.com> (raw)
In-Reply-To: <20191024134133.GC4114@hirez.programming.kicks-ass.net>



On 10/24/2019 9:41 AM, Peter Zijlstra wrote:
> On Tue, Oct 22, 2019 at 10:11:24AM -0700, kan.liang@linux.intel.com wrote:
>> From: Kan Liang <kan.liang@linux.intel.com>
>>
>> In LBR call stack mode, the depth of reconstructed LBR call stack limits
>> to the number of LBR registers. With LBR Top-of-Stack (TOS) information,
>> perf tool may stitch the stacks of two samples. The reconstructed LBR
>> call stack can break the HW limitation.
>>
>> Add a new branch sample type to retrieve LBR TOS.
>>
>> Only when the new branch sample type is set, the TOS information is
>> dumped into the PERF_SAMPLE_BRANCH_STACK output.
>> Perf tool should check the attr.branch_sample_type, and apply the
>> corresponding format for PERF_SAMPLE_BRANCH_STACK samples.
>> Otherwise, some user case may be broken. For example, users may parse a
>> perf.data, which include the new branch sample type, with an old version
>> perf tool (without the check). Users probably get incorrect information
>> without any warning.
>>
>> Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
>> ---
>>   include/linux/perf_event.h      |  2 ++
>>   include/uapi/linux/perf_event.h | 10 +++++++++-
>>   kernel/events/core.c            | 11 +++++++++++
>>   3 files changed, 22 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
>> index 61448c19a132..2b229ea1cc15 100644
>> --- a/include/linux/perf_event.h
>> +++ b/include/linux/perf_event.h
>> @@ -92,6 +92,7 @@ struct perf_raw_record {
>>   /*
>>    * branch stack layout:
>>    *  nr: number of taken branches stored in entries[]
>> + *  tos: Top-of-Stack (TOS) information. PMU specific data.
>>    *
>>    * Note that nr can vary from sample to sample
>>    * branches (to, from) are stored from most recent
>> @@ -100,6 +101,7 @@ struct perf_raw_record {
>>    */
>>   struct perf_branch_stack {
>>   	__u64				nr;
>> +	__u64				tos; /* PMU specific data */
>>   	struct perf_branch_entry	entries[0];
>>   };
>>   
>> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
>> index bb7b271397a6..b1f022190571 100644
>> --- a/include/uapi/linux/perf_event.h
>> +++ b/include/uapi/linux/perf_event.h
>> @@ -180,6 +180,8 @@ enum perf_branch_sample_type_shift {
>>   
>>   	PERF_SAMPLE_BRANCH_TYPE_SAVE_SHIFT	= 16, /* save branch type */
>>   
>> +	PERF_SAMPLE_BRANCH_LBR_TOS_SHIFT	= 17, /* save LBR TOS */
> 
> I think I prefer not having LBR here either, who knows what other
> hardware can make use of that.

Alternatively, we may put it at the end of perf_branch_sample_type_shift 
as below.

	PERF_SAMPLE_BRANCH_LBR_TOS_SHIFT	= 63, /* save LBR TOS */

It looks like we just need to do a little bit extra work in 
perf_copy_attr() to specially handle the case.

> 
> On that, you've completely failed to Cc the other architecture that
> implement PERF_SAMPLE_BRANCH.

It looks like only PowerPC implement PERF_SAMPLE_BRANCH.
Michael, any comments?

Thanks,
Kan

> 
> Aside from that I can live with this version.
> 
>> +
>>   	PERF_SAMPLE_BRANCH_MAX_SHIFT		/* non-ABI */
>>   };
>>   
>> @@ -207,6 +209,8 @@ enum perf_branch_sample_type {
>>   	PERF_SAMPLE_BRANCH_TYPE_SAVE	=
>>   		1U << PERF_SAMPLE_BRANCH_TYPE_SAVE_SHIFT,
>>   
>> +	PERF_SAMPLE_BRANCH_LBR_TOS	= 1U << PERF_SAMPLE_BRANCH_LBR_TOS_SHIFT,
>> +
>>   	PERF_SAMPLE_BRANCH_MAX		= 1U << PERF_SAMPLE_BRANCH_MAX_SHIFT,
>>   };
>>   
>> @@ -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_LBR_TOS is set
>> +	 *        u64			tos;
>> +	 *      } && PERF_SAMPLE_BRANCH_STACK
>>   	 *
>>   	 * 	{ u64			abi; # enum perf_sample_regs_abi
>>   	 * 	  u64			regs[weight(mask)]; } && PERF_SAMPLE_REGS_USER
>> diff --git a/kernel/events/core.c b/kernel/events/core.c
>> index 9ec0b0bfddbd..18b0a7d2c67e 100644
>> --- a/kernel/events/core.c
>> +++ b/kernel/events/core.c
>> @@ -6343,6 +6343,11 @@ static void perf_output_read(struct perf_output_handle *handle,
>>   		perf_output_read_one(handle, event, enabled, running);
>>   }
>>   
>> +static inline bool perf_sample_save_lbr_tos(struct perf_event *event)
>> +{
>> +	return event->attr.branch_sample_type & PERF_SAMPLE_BRANCH_LBR_TOS;
>> +}
>> +
>>   void perf_output_sample(struct perf_output_handle *handle,
>>   			struct perf_event_header *header,
>>   			struct perf_sample_data *data,
>> @@ -6432,6 +6437,8 @@ void perf_output_sample(struct perf_output_handle *handle,
>>   
>>   			perf_output_put(handle, data->br_stack->nr);
>>   			perf_output_copy(handle, data->br_stack->entries, size);
>> +			if (perf_sample_save_lbr_tos(event))
>> +				perf_output_put(handle, data->br_stack->tos);
>>   		} else {
>>   			/*
>>   			 * we always store at least the value of nr
>> @@ -6619,7 +6626,11 @@ void perf_prepare_sample(struct perf_event_header *header,
>>   		if (data->br_stack) {
>>   			size += data->br_stack->nr
>>   			      * sizeof(struct perf_branch_entry);
>> +
>> +			if (perf_sample_save_lbr_tos(event))
>> +				size += sizeof(u64);
>>   		}
>> +
>>   		header->size += size;
>>   	}
>>   
>> -- 
>> 2.17.1
>>

  reply	other threads:[~2019-10-24 15:50 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-22 17:11 [PATCH V3 00/13] Stitch LBR call stack kan.liang
2019-10-22 17:11 ` [PATCH V3 01/13] perf/core: Add new branch sample type for LBR TOS kan.liang
2019-10-24 13:41   ` Peter Zijlstra
2019-10-24 15:50     ` Liang, Kan [this message]
2019-10-22 17:11 ` [PATCH V3 02/13] perf/x86/intel: Output LBR TOS information kan.liang
2019-10-22 17:11 ` [PATCH V3 03/13] perf tools: Support new branch sample type for LBR TOS kan.liang
2019-10-22 17:11 ` [PATCH V3 04/13] perf header: Add check for event attr kan.liang
2019-10-22 17:11 ` [PATCH V3 05/13] perf pmu: Add support for PMU capabilities kan.liang
2019-10-22 17:11 ` [PATCH V3 06/13] perf header: Support CPU " kan.liang
2019-10-22 17:11 ` [PATCH V3 07/13] perf machine: Refine the function for LBR call stack reconstruction kan.liang
2019-10-22 17:11 ` [PATCH V3 08/13] perf tools: Stitch LBR call stack kan.liang
2019-10-22 17:11 ` [PATCH V3 09/13] perf report: Add option to enable the LBR stitching approach kan.liang
2019-10-22 17:11 ` [PATCH V3 10/13] perf script: " kan.liang
2019-10-22 17:11 ` [PATCH V3 11/13] perf top: " kan.liang
2019-10-22 17:11 ` [PATCH V3 12/13] perf c2c: " kan.liang
2019-10-22 17:11 ` [RFC PATCH V3 13/13] perf hist: Add fast path for duplicate entries check 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=2acd43e0-0b78-44e5-7b4e-b87c251db284@linux.intel.com \
    --to=kan.liang@linux.intel.com \
    --cc=acme@kernel.org \
    --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.