[PATCH v2 0/5] perf/x86/uncore: Overflow handling enhancements

Sandipan Das posted 5 patches 8 months ago
arch/x86/events/amd/uncore.c   | 103 ++++++++++++++++++++++++++++++++-
arch/x86/events/intel/uncore.c |  12 +---
2 files changed, 103 insertions(+), 12 deletions(-)
[PATCH v2 0/5] perf/x86/uncore: Overflow handling enhancements
Posted by Sandipan Das 8 months ago
Uncore counters on AMD processors either roll over or saturate on
overflow and the amd-uncore driver has no way of knowing if multiple
overflows have occurred between two successive pmu->read() requests for
an event. This makes the user-visible counter values inaccurate. Solve
this by periodically initiating pmu->read() in order to keep prev_count
up-to-date. The approach follows Intel's precedent in handling uncore
counters.

Previous versions can be found at:
v1: https://lore.kernel.org/all/cover.1744184837.git.sandipan.das@amd.com/

Changes in v2:
 - Add a Fixes tag for the first patch.
 - Change the hrtimer mode for both the Intel and the AMD uncore drivers
   based on Peter's suggestion.
 - Fix an issue in the UMC workaround where prev_count is not zeroed out
   after a counter is reset.

Sandipan Das (5):
  perf/x86/amd/uncore: Remove unused member from amd_uncore_ctx
  perf/x86/intel/uncore: Use HRTIMER_MODE_HARD for detecting overflows
  perf/x86/amd/uncore: Use hrtimer for handling overflows
  perf/x86/amd/uncore: Add parameter to configure hrtimer
  perf/x86/amd/uncore: Prevent UMC counters from saturating

 arch/x86/events/amd/uncore.c   | 103 ++++++++++++++++++++++++++++++++-
 arch/x86/events/intel/uncore.c |  12 +---
 2 files changed, 103 insertions(+), 12 deletions(-)

-- 
2.43.0
Re: [PATCH v2 0/5] perf/x86/uncore: Overflow handling enhancements
Posted by Ingo Molnar 7 months, 4 weeks ago
* Sandipan Das <sandipan.das@amd.com> wrote:

> Sandipan Das (5):
>   perf/x86/amd/uncore: Remove unused member from amd_uncore_ctx
>   perf/x86/intel/uncore: Use HRTIMER_MODE_HARD for detecting overflows
>   perf/x86/amd/uncore: Use hrtimer for handling overflows
>   perf/x86/amd/uncore: Add parameter to configure hrtimer
>   perf/x86/amd/uncore: Prevent UMC counters from saturating

Could you please fix your mailer to not mutiliate Cc: lines?

Cc: linux-perf-users@vger.kernel.org
Cc: peterz@infradead.org
Cc: mingo@redhat.com
Cc: acme@kernel.org
Cc: namhyung@kernel.org
Cc: mark.rutland@arm.com
Cc: alexander.shishkin@linux.intel.com
Cc: jolsa@kernel.org
Cc: irogers@google.com
Cc: adrian.hunter@intel.com
Cc: kan.liang@linux.intel.com
Cc: tglx@linutronix.de
Cc: bp@alien8.de
Cc: dave.hansen@linux.intel.com
Cc: x86@kernel.org
Cc: hpa@zytor.com
Cc: eranian@google.com
Cc: songliubraving@meta.com
Cc: ravi.bangoria@amd.com
Cc: ananth.narayan@amd.com

All these email addresses have real names, I suppose they weren't just 
written in in such a fashion?

Thanks,

	Ingo
Re: [PATCH v2 0/5] perf/x86/uncore: Overflow handling enhancements
Posted by Sandipan Das 7 months, 4 weeks ago

On 4/18/2025 2:02 PM, Ingo Molnar wrote:
> 
> * Sandipan Das <sandipan.das@amd.com> wrote:
> 
>> Sandipan Das (5):
>>   perf/x86/amd/uncore: Remove unused member from amd_uncore_ctx
>>   perf/x86/intel/uncore: Use HRTIMER_MODE_HARD for detecting overflows
>>   perf/x86/amd/uncore: Use hrtimer for handling overflows
>>   perf/x86/amd/uncore: Add parameter to configure hrtimer
>>   perf/x86/amd/uncore: Prevent UMC counters from saturating
> 
> Could you please fix your mailer to not mutiliate Cc: lines?
> 

My bad. Will fix this.

> Cc: linux-perf-users@vger.kernel.org
> Cc: peterz@infradead.org
> Cc: mingo@redhat.com
> Cc: acme@kernel.org
> Cc: namhyung@kernel.org
> Cc: mark.rutland@arm.com
> Cc: alexander.shishkin@linux.intel.com
> Cc: jolsa@kernel.org
> Cc: irogers@google.com
> Cc: adrian.hunter@intel.com
> Cc: kan.liang@linux.intel.com
> Cc: tglx@linutronix.de
> Cc: bp@alien8.de
> Cc: dave.hansen@linux.intel.com
> Cc: x86@kernel.org
> Cc: hpa@zytor.com
> Cc: eranian@google.com
> Cc: songliubraving@meta.com
> Cc: ravi.bangoria@amd.com
> Cc: ananth.narayan@amd.com
> 
> All these email addresses have real names, I suppose they weren't just 
> written in in such a fashion?
> 

And this too.