linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Luck, Tony" <tony.luck@intel.com>
To: Jonathan Perry <yonch@yonch.com>
Cc: Reinette Chatre <reinette.chatre@intel.com>,
	<linux-kernel@vger.kernel.org>, <linux-kselftest@vger.kernel.org>,
	<linux-doc@vger.kernel.org>, Jonathan Corbet <corbet@lwn.net>,
	James Morse <james.morse@arm.com>,
	Roman Storozhenko <romeusmeister@gmail.com>
Subject: Re: [PATCH 0/8] resctrl: Add perf PMU for resctrl monitoring
Date: Thu, 16 Oct 2025 14:25:57 -0700	[thread overview]
Message-ID: <aPFi5eQt1CmYXg_X@agluck-desk3> (raw)
In-Reply-To: <20251016144656.74928-1-yonch@yonch.com>

On Thu, Oct 16, 2025 at 09:46:48AM -0500, Jonathan Perry wrote:
> Motivation: perf support enables measuring cache occupancy and memory 
> bandwidth metrics on hrtimer (high resolution timer) interrupts via eBPF.
> Compared with polling from userspace, hrtimer-based reads remove 
> scheduling jitter and context switch overhead. Further, PMU reads can be 
> parallel, since the PMU read path need not lock resctrl's rdtgroup_mutex.
> Parallelization and reduced jitter enable more accurate snapshots of
> cache occupancy and memory bandwidth. [1] has more details on the 
> motivation and design.

This parallel read without rdtgroup_mutex looks worrying.

The h/w counters have limited width (24-bits on older Intel CPUs,
32-bits on AMD and Intel >= Icelake). So resctrl takes the raw
value and in get_corrected_val() figures the increment since the
previous read of the MSR to figure out how much to add to the
running per-RMID count of "chunks".

That's all inherently full of races. If perf does this at the
same time that resctrl does, then things will be corrupted
sooner or later.

You might fix it with a per-RMID spinlock in "struct arch_mbm_state"?

-Tony

  parent reply	other threads:[~2025-10-16 21:26 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-16 14:46 [PATCH 0/8] resctrl: Add perf PMU for resctrl monitoring Jonathan Perry
2025-10-16 14:46 ` [PATCH 1/8] resctrl: Pin rdtgroup for mon_data file lifetime Jonathan Perry
2025-10-16 14:46 ` [PATCH 2/8] resctrl/mon: Split RMID read init from execution Jonathan Perry
2025-10-16 14:46 ` [PATCH 3/8] resctrl/mon: Select cpumask before invoking mon_event_read() Jonathan Perry
2025-10-16 14:46 ` [PATCH 4/8] resctrl/mon: Create mon_event_setup_read() helper Jonathan Perry
2025-10-16 14:46 ` [PATCH 5/8] resctrl: Propagate CPU mask validation error via rr->err Jonathan Perry
2025-10-16 14:46 ` [PATCH 6/8] resctrl/pmu: Introduce skeleton PMU and selftests Jonathan Perry
2025-10-16 14:46 ` [PATCH 7/8] resctrl/pmu: Use mon_event_setup_read() and validate CPU Jonathan Perry
2025-10-16 14:46 ` [PATCH 8/8] resctrl/pmu: Implement .read via direct RMID read; add LLC selftest Jonathan Perry
2025-10-16 21:25 ` Luck, Tony [this message]
2025-10-16 21:51   ` [PATCH 0/8] resctrl: Add perf PMU for resctrl monitoring Luck, Tony
2025-10-17 18:17     ` Jonathan Perry

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=aPFi5eQt1CmYXg_X@agluck-desk3 \
    --to=tony.luck@intel.com \
    --cc=corbet@lwn.net \
    --cc=james.morse@arm.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=reinette.chatre@intel.com \
    --cc=romeusmeister@gmail.com \
    --cc=yonch@yonch.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).