From: Peter Zijlstra <peterz@infradead.org>
To: kan.liang@linux.intel.com
Cc: mingo@redhat.com, acme@kernel.org, linux-kernel@vger.kernel.org,
mark.rutland@arm.com, alexander.shishkin@linux.intel.com,
jolsa@kernel.org, namhyung@kernel.org, irogers@google.com,
adrian.hunter@intel.com, ak@linux.intel.com, eranian@google.com,
alexey.v.bayduraev@linux.intel.com, tinghao.zhang@intel.com,
Sandipan Das <sandipan.das@amd.com>,
Ravi Bangoria <ravi.bangoria@amd.com>,
Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Subject: Re: [PATCH V2 2/6] perf: Add branch stack extension
Date: Wed, 2 Aug 2023 23:58:14 +0200 [thread overview]
Message-ID: <20230802215814.GH231007@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20230522113040.2329924-2-kan.liang@linux.intel.com>
On Mon, May 22, 2023 at 04:30:36AM -0700, kan.liang@linux.intel.com wrote:
> From: Kan Liang <kan.liang@linux.intel.com>
>
> Currently, the extra information of a branch entry is stored in a u64
> space. With more and more information added, the space is running out.
> For example, the information of occurrences of events will be added for
> each branch.
>
> Add an extension space to record the new information for each branch
> entry. The space is appended after the struct perf_branch_stack.
>
> Add a bit in struct perf_branch_entry to indicate whether the extra
> information is included.
>
> Reviewed-by: Andi Kleen <ak@linux.intel.com>
> Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
> Cc: Sandipan Das <sandipan.das@amd.com>
> Cc: Ravi Bangoria <ravi.bangoria@amd.com>
> Cc: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
> ---
>
> New patch
> - Introduce a generic extension space which can be used to
> store the LBR event information for Intel. It can also be used by
> other ARCHs for the other purpose.
> - Add a new bit in struct perf_branch_entry to indicate whether the
> extra information is included.
Bah.. I don't like this, also the actual format isn't clear to me.
The uapi part is severely lacking, it just adds the ext:1 thing, but
doesn't describe what if anything happens when it's set.
The internal perf_branch_stack_ext thing is just that, internal.
Additionally it contains a nr member, which seems to suggest it can be
different from the number of entries in the branch-stack itself -- which
would be odd indeed.
So we have an 'ext' bit per branch entry to indicate the existance of
this extra data, this again suggests no 1:1 correspondence, but at most
one extra entry per set bit.
Parsing this will be pretty horrible, no?
So what we have now is:
{ u64 nr;
{ u64 hw_idx; } && PERF_SAMPLE_BRANCH_HW_INDEX
{ u64 from, to, flags; } lbr[nr];
} && PERF_SAMPLE_BRANCH_STACK
and AFAICT you're doing:
{ u64 nr;
{ u64 hw_idx; } && PERF_SAMPLE_BRANCH_HW_INDEX
{ u64 from, to, flags; } lbr[nr];
+ { u64 nr2;
+ { u64 extra; } extra[nr2];
+ } && OR_i{lbr[i].flags.ext}
} && PERF_SAMPLE_BRANCH_STACK
Which is pretty horrific, no? The straight forward:
{ u64 nr;
{ u64 hw_idx; } && PERF_SAMPLE_BRANCH_HW_INDEX
{ u64 from, to, flags; } lbr[nr];
+ { u64 extra; } ext[nr] && SOMETHING
} && PERF_SAMPLE_BRANCH_STACK
Or perhaps even:
{ u64 nr;
{ u64 hw_idx; } && PERF_SAMPLE_BRANCH_HW_INDEX
{ u64 from, to, flags;
+ u64 extra; && SOMETHING
} lbr[nr];
} && PERF_SAMPLE_BRANCH_STACK
With the obvious question what 'SOMETHING' should be. I suppose
PERF_SAMPLE_BRANCH_EXTRA was considered and discarded?
Implementing the last suggestion wouldn't even be too bad, since having
PERF_SAMPLE_BRANCH_EXTRA set, we know to allocate and cast the existing
perf_sample_data::br_stack to a convenient new type, something like:
struct perf_branch_entry_ext {
__u64 from;
__u64 to;
__u64 mispred:1, /* target mispredicted */
predicted:1,/* target predicted */
in_tx:1, /* in transaction */
abort:1, /* transaction abort */
cycles:16, /* cycle count to last branch */
type:4, /* branch type */
spec:2, /* branch speculation info */
new_type:4, /* additional branch type */
priv:3, /* privilege level */
reserved:31;
__u64 extra;
};
Except at that point I think I would suggest doing s/EXTRA/COUNTERS/g
and making it something like:
union {
__u64 counters;
__u8 c[8];
};
Or something daft like that.
Wouldn't all that make *MUCH* more sense?
next prev parent reply other threads:[~2023-08-02 21:58 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-22 11:30 [PATCH V2 1/6] perf/x86/intel: Add Grand Ridge and Sierra Forest kan.liang
2023-05-22 11:30 ` [PATCH V2 2/6] perf: Add branch stack extension kan.liang
2023-05-23 6:03 ` Sandipan Das
2023-05-23 13:08 ` Liang, Kan
2023-08-02 21:58 ` Peter Zijlstra [this message]
2023-08-03 14:22 ` Liang, Kan
2023-05-22 11:30 ` [PATCH V2 3/6] perf: Support branch events kan.liang
2023-05-22 11:30 ` [PATCH V2 4/6] perf/x86/intel: Support LBR event logging kan.liang
2023-05-22 11:30 ` [PATCH V2 5/6] tools headers UAPI: Sync include/uapi/linux/perf_event.h header with the kernel kan.liang
2023-05-22 11:30 ` [PATCH V2 6/6] perf tools: Add branch event knob kan.liang
2023-05-22 20:26 ` [PATCH V2 1/6] perf/x86/intel: Add Grand Ridge and Sierra Forest Peter Zijlstra
2023-05-22 20:42 ` Luck, Tony
2023-05-22 20:48 ` Peter Zijlstra
2023-06-07 21:43 ` Luck, Tony
2023-06-08 7:24 ` Peter Zijlstra
2023-06-08 16:20 ` Luck, Tony
2023-06-29 22:39 ` Tony Luck
2023-08-02 15:01 ` Peter Zijlstra
2023-06-06 12:42 ` Liang, Kan
2023-06-06 13:24 ` Peter Zijlstra
2023-06-06 16:16 ` Liang, Kan
2023-06-06 18:17 ` Peter Zijlstra
2023-06-06 18:34 ` Liang, Kan
2023-06-06 19:37 ` Peter Zijlstra
2023-06-06 19:54 ` Liang, Kan
2023-08-09 20:04 ` [tip: perf/core] perf/x86/intel: Add Crestmont PMU tip-bot2 for 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=20230802215814.GH231007@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=alexey.v.bayduraev@linux.intel.com \
--cc=atrajeev@linux.vnet.ibm.com \
--cc=eranian@google.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=ravi.bangoria@amd.com \
--cc=sandipan.das@amd.com \
--cc=tinghao.zhang@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).