[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231019111202.GJ36211@noisy.programming.kicks-ass.net>
Date: Thu, 19 Oct 2023 13:12:02 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: kan.liang@...ux.intel.com
Cc: mingo@...hat.com, acme@...nel.org, linux-kernel@...r.kernel.org,
mark.rutland@....com, alexander.shishkin@...ux.intel.com,
jolsa@...nel.org, namhyung@...nel.org, irogers@...gle.com,
adrian.hunter@...el.com, ak@...ux.intel.com, eranian@...gle.com,
alexey.v.bayduraev@...ux.intel.com, tinghao.zhang@...el.com
Subject: Re: [PATCH V4 4/7] perf/x86/intel: Support LBR event logging
On Wed, Oct 04, 2023 at 11:40:41AM -0700, kan.liang@...ux.intel.com wrote:
> +static __always_inline void get_lbr_events(struct cpu_hw_events *cpuc,
> + int i, u64 info)
> +{
> + /*
> + * The later code will decide what content can be disclosed
> + * to the perf tool. It's no harmful to unconditionally update
> + * the cpuc->lbr_events.
> + * Pleae see intel_pmu_lbr_event_reorder()
> + */
> + cpuc->lbr_events[i] = info & LBR_INFO_EVENTS;
> +}
You could be forcing an extra cachemiss here. A long time ago I had
hacks to profile perf with perf, but perhaps PT can be abused for that
now?
Powered by blists - more mailing lists