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
Subject: Re: [PATCH V4 4/7] perf/x86/intel: Support LBR event logging
Date: Thu, 19 Oct 2023 12:52:31 +0200 [thread overview]
Message-ID: <20231019105231.GG36211@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20231004184044.3062788-4-kan.liang@linux.intel.com>
On Wed, Oct 04, 2023 at 11:40:41AM -0700, kan.liang@linux.intel.com wrote:
> +#define ARCH_LBR_EVENT_LOG_WIDTH 2
> +#define ARCH_LBR_EVENT_LOG_MASK 0x3
event log ?
> +static __always_inline void intel_pmu_update_lbr_event(u64 *lbr_events, int idx, int pos)
> +{
> + u64 logs = *lbr_events >> (LBR_INFO_EVENTS_OFFSET +
> + idx * ARCH_LBR_EVENT_LOG_WIDTH);
> +
> + logs &= ARCH_LBR_EVENT_LOG_MASK;
> + *lbr_events |= logs << (pos * ARCH_LBR_EVENT_LOG_WIDTH);
> +}
> +
> +/*
> + * The enabled order may be different from the counter order.
> + * Update the lbr_events with the enabled order.
> + */
> +static void intel_pmu_lbr_event_reorder(struct cpu_hw_events *cpuc,
> + struct perf_event *event)
> +{
> + int i, j, pos = 0, enabled[X86_PMC_IDX_MAX];
> + struct perf_event *leader, *sibling;
> +
> + leader = event->group_leader;
> + if (branch_sample_counters(leader))
> + enabled[pos++] = leader->hw.idx;
> +
> + for_each_sibling_event(sibling, leader) {
> + if (!branch_sample_counters(sibling))
> + continue;
> + enabled[pos++] = sibling->hw.idx;
> + }
Ok, so far so good: enabled[x] = y, is a mapping of hardware index (y)
to group order (x).
Although I would perhaps name that order[] instead of enabled[].
> +
> + if (!pos)
> + return;
How would we ever get here if this is the case?
> +
> + for (i = 0; i < cpuc->lbr_stack.nr; i++) {
> + for (j = 0; j < pos; j++)
> + intel_pmu_update_lbr_event(&cpuc->lbr_events[i], enabled[j], j);
But this confuses me... per that function it:
- extracts counter value for enabled[j] and,
- or's it into the same variable at j
But what if j is already taken by something else?
That is, suppose enabled[] = {3,2,1,0}, and lbr_events = 11 10 01 00
Then: for (j) intel_pmu_update_lbt_event(&lbr_event, enabled[j], j);
0: 3->0, 11 10 01 00 -> 11 10 01 11
1: 2->1, 11 10 01 11 -> 11 10 11 11
2: 1->2, 11 10 11 11 -> 11 11 11 11
> +
> + /* Clear the original counter order */
> + cpuc->lbr_events[i] &= ~LBR_INFO_EVENTS;
> + }
> +}
Would not something like:
src = lbr_events[i];
dst = 0;
for (j = 0; j < pos; j++) {
cnt = (src >> enabled[j]*2) & 3;
dst |= cnt << j*2
}
lbr_events[i] = dst;
be *FAR* clearer, and actually work?
next prev parent reply other threads:[~2023-10-19 10:52 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-04 18:40 [PATCH V4 1/7] perf: Add branch stack counters kan.liang
2023-10-04 18:40 ` [PATCH V4 2/7] perf/x86: Add PERF_X86_EVENT_NEEDS_BRANCH_STACK flag kan.liang
2023-10-04 18:40 ` [PATCH V4 3/7] perf: Add branch_sample_call_stack kan.liang
2023-10-04 18:40 ` [PATCH V4 4/7] perf/x86/intel: Support LBR event logging kan.liang
2023-10-19 9:23 ` Peter Zijlstra
2023-10-19 13:56 ` Liang, Kan
2023-10-19 9:26 ` Peter Zijlstra
2023-10-19 13:58 ` Liang, Kan
2023-10-19 10:52 ` Peter Zijlstra [this message]
2023-10-19 14:26 ` Liang, Kan
2023-10-19 18:18 ` Peter Zijlstra
2023-10-19 11:00 ` Peter Zijlstra
2023-10-19 14:28 ` Liang, Kan
2023-10-19 11:09 ` Peter Zijlstra
2023-10-19 14:31 ` Liang, Kan
2023-10-19 11:12 ` Peter Zijlstra
2023-10-20 12:45 ` Liang, Kan
2023-10-04 18:40 ` [PATCH V4 5/7] tools headers UAPI: Sync include/uapi/linux/perf_event.h header with the kernel kan.liang
2023-10-04 18:40 ` [PATCH V4 6/7] perf header: Support num and width of branch counters kan.liang
2023-10-04 18:40 ` [PATCH V4 7/7] perf tools: Add branch counter knob kan.liang
2023-10-16 17:48 ` [PATCH V4 1/7] perf: Add branch stack counters Liang, Kan
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=20231019105231.GG36211@noisy.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=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=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 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.