From: Peter Zijlstra <peterz@infradead.org>
To: kan.liang@linux.intel.com
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,
Michael Ellerman <mpe@ellerman.id.au>
Subject: Re: [PATCH V3 01/13] perf/core: Add new branch sample type for LBR TOS
Date: Thu, 24 Oct 2019 15:41:33 +0200 [thread overview]
Message-ID: <20191024134133.GC4114@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20191022171136.4022-2-kan.liang@linux.intel.com>
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.
On that, you've completely failed to Cc the other architecture that
implement PERF_SAMPLE_BRANCH.
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
>
next prev parent reply other threads:[~2019-10-24 13:41 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 [this message]
2019-10-24 15:50 ` Liang, Kan
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=20191024134133.GC4114@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=eranian@google.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--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=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.