From: Reinette Chatre <reinette.chatre@intel.com>
To: Babu Moger <babu.moger@amd.com>, <tony.luck@intel.com>, <bp@alien8.de>
Cc: <x86@kernel.org>, <Dave.Martin@arm.com>, <james.morse@arm.com>,
<corbet@lwn.net>, <skhan@linuxfoundation.org>, <tglx@kernel.org>,
<mingo@redhat.com>, <dave.hansen@linux.intel.com>,
<hpa@zytor.com>, <linux-kernel@vger.kernel.org>,
<linux-doc@vger.kernel.org>, <eranian@google.com>,
<peternewman@google.com>
Subject: Re: [PATCH 1/2] x86/resctrl, Documentation: Keep mbm_assign_mode "default" on boot
Date: Fri, 17 Jul 2026 15:56:38 -0700 [thread overview]
Message-ID: <d337915a-ef4c-43b2-a915-e97381b7dca0@intel.com> (raw)
In-Reply-To: <8cb66e18e32e4087a9712c1e68ee6da614efe244.1784322818.git.babu.moger@amd.com>
Hi Babu,
On 7/17/26 2:13 PM, Babu Moger wrote:
> The kernel currently enables the ABMC-based "mbm_event" mode by default on
> hardware that supports it. However, this can cause bandwidth monitoring
> failures with existing userspace tools such as pqos.
>
> The pqos tool mounts the resctrl filesystem and creates 16 or more resctrl
> groups by default. On systems with 32 or fewer ABMC counters, this default
> configuration can consume all available counters, since each group requires
> one counter for local MBM and another for total MBM. If additional
> monitoring groups are created, counter resources are exhausted and pqos
> tool reports memory bandwidth counters as zero for those groups.
It is not obvious to me that this is a problem. If I understand correctly
there are two scenarios possible with this pqos behavior:
- ABMC is not in use ("mbm_assign_mode" is set to "default")
- pqos can create 16 or more monitor groups
- hardware still supports a limited number of counters with consequence that
underlying counters reset at any time as the different monitoring groups
need to be tracked.
- pqos can read monitoring data of all 16 monitor groups, sometimes reading the
events would return "Unavailable", sometimes reading the events return data.
- *None* of the monitoring numbers returned are guaranteed to be accurate.
- ABMC is in use ("mbm_assign_mode" is set to "mbm_event"):
- pqos can create 16 or more monitor groups
- only a subset of monitoring groups have counters assigned and these counters
are guaranteed to only track the monitor groups/events they are assigned to
- pqos can read monitoring data of all 16 monitor groups with two possibilities:
- monitor group/event has counter assigned: monitoring numbers are guaranteed to be accurate
- monitor group/event does not have counter assigned: monitoring numbers return 0
If my understanding is correct then the preference is to rather have wrong data than
see 0? This does not sound right. What am I missing?
The changelog starts with "this can cause bandwidth monitoring failures with existing
userspace tools such as pqos". How could returning accurate memory bandwidth data be
considered a failure? How does this issue manifest itself?
>
> Avoid this compatibility issue by leaving mbm_assign_mode in the "default"
> mode during initialization. Users who want to use ABMC can continue to
> enable it explicitly:
>
> echo mbm_event > /sys/fs/resctrl/info/L3_MON/mbm_assign_mode
>
> Update the resctrl documentation to reflect the new boot-time default and
> adjust the mbm_assign_mode examples accordingly.
>
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> ---
> There are plans to enable "mbm_event" by default once additional counters
> are available. For now, keep the default mode to maintain compatibility
> with existing tools.
This is not ideal. resctrl should aim to provide a consistent user interface
across kernel versions.
Reinette
prev parent reply other threads:[~2026-07-17 22:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-17 21:13 [PATCH 1/2] x86/resctrl, Documentation: Keep mbm_assign_mode "default" on boot Babu Moger
2026-07-17 21:13 ` [PATCH 2/2] x86/resctrl: Fix ABMC counter programming for extended counter ranges Babu Moger
2026-07-17 22:56 ` Reinette Chatre [this message]
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=d337915a-ef4c-43b2-a915-e97381b7dca0@intel.com \
--to=reinette.chatre@intel.com \
--cc=Dave.Martin@arm.com \
--cc=babu.moger@amd.com \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=eranian@google.com \
--cc=hpa@zytor.com \
--cc=james.morse@arm.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peternewman@google.com \
--cc=skhan@linuxfoundation.org \
--cc=tglx@kernel.org \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
/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.