lkml.org 
[lkml]   [2023]   [Aug]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH V2 2/6] perf: Add branch stack extension
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?

\
 
 \ /
  Last update: 2023-08-02 23:59    [W:0.469 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site