[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240620083810.GU31592@noisy.programming.kicks-ass.net>
Date: Thu, 20 Jun 2024 10:38:10 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: kan.liang@...ux.intel.com
Cc: mingo@...nel.org, acme@...nel.org, namhyung@...nel.org,
irogers@...gle.com, adrian.hunter@...el.com,
alexander.shishkin@...ux.intel.com, linux-kernel@...r.kernel.org,
ak@...ux.intel.com, eranian@...gle.com,
Sandipan Das <sandipan.das@....com>,
Ravi Bangoria <ravi.bangoria@....com>,
silviazhao <silviazhao-oc@...oxin.com>,
CodyYao-oc <CodyYao-oc@...oxin.com>
Subject: Re: [RESEND PATCH 08/12] perf/x86: Extend event update interface
On Tue, Jun 18, 2024 at 08:10:40AM -0700, kan.liang@...ux.intel.com wrote:
> From: Kan Liang <kan.liang@...ux.intel.com>
>
> The current event update interface directly reads the values from the
> counter, but the values may not be the accurate ones users require. For
> example, the sample read feature wants the counter value of the member
> events when the leader event is overflow. But with the current
> implementation, the read (event update) actually happens in the NMI
> handler. There may be a small gap between the overflow and the NMI
> handler. The new Intel PEBS counters snapshotting feature can provide
> the accurate counter value in the overflow. The event update interface
> has to be updated to apply the given accurate values.
>
> Pass the accurate values via the event update interface. If the value is
> not available, still directly read the counter.
>
> For some cases, e.g., intel_update_topdown_event, there could be more
> than one counter/register are read. Using u64 * rather than u64 as the
> new parameter.
The stronger argument is that there is no special value to distinguish
between there begin an argument and there not being one. You cannot have
!val, because 0 might be a valid rdpmc() value.
Powered by blists - more mailing lists