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>,
<rdunlap@infradead.org>, <tglx@kernel.org>, <mingo@redhat.com>,
<dave.hansen@linux.intel.com>, <hpa@zytor.com>, <kas@kernel.org>,
<rick.p.edgecombe@intel.com>, <linux-kernel@vger.kernel.org>,
<linux-doc@vger.kernel.org>, <linux-coco@lists.linux.dev>,
<kvm@vger.kernel.org>
Subject: Re: [PATCH v3 3/3] x86,fs/resctrl: Keep mbm_assign_mode in default mode at boot
Date: Wed, 7 Oct 2026 15:21:51 -0700 [thread overview]
Message-ID: <a76ccccb-7070-43aa-8bf6-1db8091824ed@intel.com> (raw)
In-Reply-To: <c2ca9eec-57f2-41b2-b8fa-4ed193b5b2dc@amd.com>
Hi Babu,
On 10/7/26 11:54 AM, Babu Moger wrote:
> On 10/6/26 12:53, Reinette Chatre wrote:
>> On 10/2/26 2:26 PM, Babu Moger wrote:
...
>>> workflows that monitor a subset of groups at a time and rotate
>>> assignments as needed.
>>>
>>> resctrl enables the "mbm_event" mode by default on hardware that
>>> supports it. That breaks the pqos tool [1], which assumes the historical
>>> default mode. pqos treats a non-numeric event read as zero bandwidth. It
>>> creates 16 or more monitoring groups and uses two counters per group.
>>> On a platform with 32 counters per domain, that consumes the pool, so
>>> further groups read "Unassigned" and pqos reports 0 MB/s for them:
>>>
>>> $sudo pqos -m all:0-4
>>> CORE IPC MISSES LLC[KB] MBL[MB/s] MBR[MB/s]
>>> 0 0.69 16k 192.0 0.0 0.0
>>> 1 0.40 3k 0.0 0.0 0.0
>>> 2 0.44 1k 64.0 0.0 0.0
>>> 3 0.39 1k 64.0 0.0 0.0
>>> 4 0.43 1k 0.0 0.0 0.0
>>>
>>> Leave mbm_assign_mode in "default" mode during initialization. Default
>>> mode uses one counter per monitoring group. On existing AMD platforms
>>> that pool is 64 counters and may be larger on newer hardware. The
>>> "mbm_event" mode uses two counters per group, so 32 counters cover only
>>> 16 groups.
>>>
>>> Deployments within that pool receive accurate bandwidth measurements
>>> with default mode. The hardware supports 4096 monitoring groups. Beyond
>>> that pool, readings may be misleading or "Unavailable", with no
>>
>> At this point I am lost because the word "pool" is used to mean three
>> different things. It is used for the number of "ABMC counters" as well
>> as the number of "non-ABMC counters" that exist on the same platform,
>> above it seems to be used for number of RMIDs (number of monitoring
>> groups) also. Could you please add some context at beginning of
>> changelog to introduce the various counts applicable to the description,
>> associate unique terms to these counts at that time, and then use
>> those unique terms in the rest of the changelog?
>
> Sure.
> I can name as "ABMC counters pool" and "default active counters pool"
hmmm ... "active counter" is new term that, when grepping this series,
fs/resctrl/*, and arch/x86/kernel/cpu/resctrl/*, does not appear a single
time.
If this new term is needed then please include a definition as part of the
changelog context that makes it obvious what it refers to.
Reinette
next prev parent reply other threads:[~2026-10-07 22:23 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-02 21:26 [PATCH v3 0/3] x86,fs/resctrl: Keep default MBM mode at boot and fix ABMC Babu Moger
2026-10-02 21:26 ` [PATCH v3 1/3] x86/resctrl: Fix ABMC counter programming Babu Moger
2026-10-06 17:47 ` Reinette Chatre
2026-10-07 16:33 ` Babu Moger
2026-10-02 21:26 ` [PATCH v3 2/3] fs/resctrl: Assign counters to existing groups when enabling mbm_event Babu Moger
2026-10-06 17:51 ` Reinette Chatre
2026-10-07 18:16 ` Babu Moger
2026-10-07 22:21 ` Reinette Chatre
2026-10-07 23:45 ` Moger, Babu
2026-10-02 21:26 ` [PATCH v3 3/3] x86,fs/resctrl: Keep mbm_assign_mode in default mode at boot Babu Moger
2026-10-06 17:53 ` Reinette Chatre
2026-10-07 18:54 ` Babu Moger
2026-10-07 22:21 ` Reinette Chatre [this message]
2026-10-07 23:47 ` Moger, Babu
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=a76ccccb-7070-43aa-8bf6-1db8091824ed@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=hpa@zytor.com \
--cc=james.morse@arm.com \
--cc=kas@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=rdunlap@infradead.org \
--cc=rick.p.edgecombe@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®