x86/resctrl: Keep default MBM mode at boot and fix ABMC

Memory Bandwidth Monitoring (MBM) can report incorrect values when ABMC is enabled on systems supporting more than 32 ABMC counters. As the number of active monitoring groups increases beyond the range supported by the existing counter ID encoding, programming an ABMC counter may inadvertently affect a different counter, resulting in unexpected counter resets and abnormally large MBM readings.

The issue originates from the ABMC counter programming interface in the L3_QOS_ABMC_CFG MSR. The counter ID field is currently defined as 5 bits, which limits the addressable counter range to 32 counters. On systems implementing more than 32 ABMC counters, counter IDs above 31 cannot be encoded correctly. Consequently, programming a counter ID beyond the supported range may target an unintended counter and reset bandwidth statistics associated with another monitoring group.

While updating this logic, it was also observed that the bw_src field, which encodes the RMID, is currently at its 12-bit limit with support for 4096 RMIDs. This field also needs to be updated for future expansion.

Also found one more pre-existing issue. This union structure can truncate data on 32-bit x86 systems when unsigned long is used.

Fix the issues with the following changes:

1. Update the cntr_id field handling to support the full hardware ABMC counter range and ensure that counter programming does not interfere with unrelated counters.

2. Expand the bw_src field to 15 bits.

3. Change "unsigned long" to u64 to fix truncation on 32-bit x86.

The AMD64 Architecture Programmer's Manual [1] available at [2] will be updated accordingly in a future revision to document the expanded cntr_id and bw_src field definitions.

[1] AMD64 Architecture Programmer's Manual Volume 2: System Programming, Publication #24593, Revision 3.41, Section 19.3.3.3 "Assignable Bandwidth Monitoring (ABMC)"

Fixes 84ecefb76674 ("x86/resctrl: Add data structures and definitions for ABMC assignment")

Signed-off-by Babu Moger <[email protected]>

Link https://bugzilla.kernel.org/show_bug.cgi?id=206537 # [2]

---

Hi Babu,

What does the "for extended counter ranges" in subject refer to? As I understand "extended events" is another term for ABMC so this seems redundant? "counter ranges" also just seems to refer to one "part" of this patch so perhaps it could just be:
x86/resctrl: Fix ABMC counter programming

Quoted 19 lines

Memory Bandwidth Monitoring (MBM) can report incorrect values when ABMC is enabled on systems supporting more than 32 ABMC counters. As the number of active monitoring groups increases beyond the range supported by the existing counter ID encoding, programming an ABMC counter may inadvertently affect a different counter, resulting in unexpected counter resets and abnormally large MBM readings.

The issue originates from the ABMC counter programming interface in the L3_QOS_ABMC_CFG MSR. The counter ID field is currently defined as 5 bits, which limits the addressable counter range to 32 counters. On systems implementing more than 32 ABMC counters, counter IDs above 31 cannot be encoded correctly. Consequently, programming a counter ID beyond the supported range may target an unintended counter and reset bandwidth statistics associated with another monitoring group.

While updating this logic, it was also observed that the bw_src field, which encodes the RMID, is currently at its 12-bit limit with support for 4096 RMIDs. This field also needs to be updated for future expansion.

Quoted 8 lines

Also found one more pre-existing issue. This union structure can truncate data on 32-bit x86 systems when unsigned long is used.

Fix the issues with the following changes:

1. Update the cntr_id field handling to support the full hardware ABMC counter range and ensure that counter programming does not interfere with unrelated counters.

Sashiko's assessment that this statement is not accurate looks correct to me.

Looks like the enumeration needs a check to limit the number of supported counters if the hardware supports more than what can be configured? It seems awkward that such hardware could exist and unclear why the spec has a mismatch in

the number of bits here. Even if cntr_id expands further to use the remaining reserved bits it would still not be sufficient to configure all the numbers that hardware may claim to support. Are there perhaps more field width changes in this upcoming spec update?

Quoted 3 lines

2. Expand the bw_src field to 15 bits.

Do the comments describing the RMID field width when reading the monitoring data (__cntr_id_read() and __rmid_read_phys()) need an update also?

Quoted 3 lines

3. Change "unsigned long" to u64 to fix truncation on 32-bit x86.

Sashiko found that this change by itself is not sufficient to address issues with 32-bit. What do you think of dropping this part of the patch and instead adding your support to:

https://lore.kernel.org/lkml/[email protected]/ ?

Quoted 5 lines

The AMD64 Architecture Programmer's Manual [1] available at [2] will be updated accordingly in a future revision to document the expanded cntr_id and bw_src field definitions.

This changelog uses a lot of text to describe one of these spec updates and then, seemingly as an afterthought, describe two more changes in a way that hints that these should be separate patches.

Could the changelog be simplified (after dropping the 64-bit change) to something like:

AMD's Assignable Bandwidth Monitoring Counters (ABMC) are configured via MSR_IA32_L3_QOS_ABMC_CFG. The architecture [1] received an update that increases the width of two of the MSR's fields:

1. The counter ID (represented by l3_qos_abmc_cfg.split.cntr_id) increases from 5 to 12 bits.

2. The bandwidth source (represented by l3_qos_abmc_cfg.split.bw_src), used for the RMID, increases from 12 to 15 bits.

Use the new field widths. The number of supported counters and RMID are enumerated separately. Designate this update as a fix to original enabling to avoid misconfigurations resulting from truncating the counter ID and RMID on hardware that support a large number of these IDs.

The changelog is just a suggestion based on its current form - other potential changes like the comments and enumeration checks are not captured by it, but should be if/when they are added.

Quoted 7 lines

[1] AMD64 Architecture Programmer's Manual Volume 2: System Programming, Publication #24593, Revision 3.41, Section 19.3.3.3 "Assignable Bandwidth Monitoring (ABMC)"

Fixes 84ecefb76674 ("x86/resctrl: Add data structures and definitions for ABMC assignment")

Is this a stable candidate?

Quoted 1 line · Reinette Chatre

On 9/4/26 11:06 AM, Babu Moger wrote:

Quoted 7 lines

Quoted 6 lines

Fix the issues with the following changes:

1. Update the cntr_id field handling to support the full hardware ABMC counter range and ensure that counter programming does not interfere with unrelated counters.

Quoted 5 lines

Sashiko's assessment that this statement is not accurate looks correct to me.

Looks like the enumeration needs a check to limit the number of supported counters if the hardware supports more than what can be configured? It seems awkward that such hardware could exist and unclear why the spec has a mismatch in

You're right. The spec overlooked this scenario. I've notified the concerned team.

Do you want me add this check?

-               r->mon.num_mbm_cntrs = (ebx & GENMASK(15, 0)) + 1; +               r->mon.num_mbm_cntrs = (ebx & GENMASK(12, 0)) + 1;

Quoted 5 lines

the number of bits here. Even if cntr_id expands further to use the remaining reserved bits it would still not be sufficient to configure all the numbers that hardware may claim to support. Are there perhaps more field width changes in this upcoming spec update?

Two fields(ctrl_id and bw_src) in here are changing for this register. I dont know about other changes yet.

Quoted 2 lines

Quoted 2 lines

Quoted 4 lines

Quoted 1 line

2. Expand the bw_src field to 15 bits.

Do the comments describing the RMID field width when reading the monitoring data (__cntr_id_read() and __rmid_read_phys()) need an update also?

The RMID field width is expected to change. We can revisit this when that happens.

Quoted 7 lines

Quoted 1 line

3. Change "unsigned long" to u64 to fix truncation on 32-bit x86.

Sashiko found that this change by itself is not sufficient to address issues with 32-bit. What do you think of dropping this part of the patch and instead adding your support to:

https://lore.kernel.org/lkml/[email protected]/ ?

Yes. I agree and support that approach. Looks like all the maintainers are inline with dropping 32. Will drop this change.

Quoted 2 lines · Babu Moger

Quoted 1 line · Reinette Chatre

On 9/4/26 11:06 AM, Babu Moger wrote:

...

Quoted 14 lines

Quoted 7 lines

Quoted 6 lines

Fix the issues with the following changes:

1. Update the cntr_id field handling to support the full hardware ABMC counter range and ensure that counter programming does not interfere with unrelated counters.

Quoted 5 lines

Sashiko's assessment that this statement is not accurate looks correct to me.

Looks like the enumeration needs a check to limit the number of supported counters if the hardware supports more than what can be configured? It seems awkward that such hardware could exist and unclear why the spec has a mismatch in

Quoted 8 lines

You're right. The spec overlooked this scenario. I've notified the concerned team.

Do you want me add this check?

-               r->mon.num_mbm_cntrs = (ebx & GENMASK(15, 0)) + 1; +               r->mon.num_mbm_cntrs = (ebx & GENMASK(12, 0)) + 1;

Yes please.

Quoted 10 lines

Quoted 5 lines

the number of bits here. Even if cntr_id expands further to use the remaining reserved bits it would still not be sufficient to configure all the numbers that hardware may claim to support. Are there perhaps more field width changes in this upcoming spec update?

Two fields(ctrl_id and bw_src) in here are changing for this register. I dont know about other changes yet.

Quoted 2 lines

Quoted 2 lines

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

2. Expand the bw_src field to 15 bits.

Do the comments describing the RMID field width when reading the monitoring data (__cntr_id_read() and __rmid_read_phys()) need an update also?

The RMID field width is expected to change. We can revisit this when that happens.

This patch is that change, no? bw_src is expanded to 15 bits, and bw_src contains the RMID.

This is the new RMID field width for monitoring configuration, after configuration the counter needs to be read for the monitoring data via MSR_IA32_QM_EVTSEL and per __cntr_id_read() the RMID field is still restricted (although not enforce by resctrl) to 12 bits:

* 43:32 RMID RMID or counter ID in ABMC mode

resctrl also supports switching between "default" and "mbm_event" mode and there is no support for the number of RMIDs changing between the modes ... this reading an event in "default" mode should support the same number of RMIDs as "mbm_event" mode and we see in __rmid_read_phys() (although, again not enforced) that it supports even fewer bits for RMID

IA32_QM_EVTSEL.RMID (bits 41:32) are configured with valid RMID

Looks like after this patch there are quite a few different field widths for RMID between what is documented, used directly, and actually enforced.

Hi Babu,

Quoted 30 lines · Reinette Chatre

Quoted 2 lines · Babu Moger

Quoted 1 line · Reinette Chatre

On 9/4/26 11:06 AM, Babu Moger wrote:

...

Quoted 14 lines

Quoted 7 lines

Quoted 6 lines

Fix the issues with the following changes:

1. Update the cntr_id field handling to support the full hardware ABMC counter range and ensure that counter programming does not interfere with unrelated counters.

Quoted 5 lines

Sashiko's assessment that this statement is not accurate looks correct to me.

Looks like the enumeration needs a check to limit the number of supported counters if the hardware supports more than what can be configured? It seems awkward that such hardware could exist and unclear why the spec has a mismatch in

Quoted 8 lines

You're right. The spec overlooked this scenario. I've notified the concerned team.

Do you want me add this check?

-               r->mon.num_mbm_cntrs = (ebx & GENMASK(15, 0)) + 1; +               r->mon.num_mbm_cntrs = (ebx & GENMASK(12, 0)) + 1;

Yes please.

Quoted 22 lines

Quoted 11 lines

Quoted 6 lines

the number of bits here. Even if cntr_id expands further to use the remaining reserved bits it would still not be sufficient to configure all the numbers that hardware may claim to support. Are there perhaps more field width changes in this upcoming spec update?

Two fields(ctrl_id and bw_src) in here are changing for this register. I dont know about other changes yet.

Quoted 2 lines

Quoted 2 lines

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

2. Expand the bw_src field to 15 bits.

Do the comments describing the RMID field width when reading the monitoring data (__cntr_id_read() and __rmid_read_phys()) need an update also?

The RMID field width is expected to change. We can revisit this when that happens.

This patch is that change, no? bw_src is expanded to 15 bits, and bw_src contains the RMID.

Quoted 6 lines

This is the new RMID field width for monitoring configuration, after configuration the counter needs to be read for the monitoring data via MSR_IA32_QM_EVTSEL and per __cntr_id_read() the RMID field is still restricted (although not enforce by resctrl) to 12 bits:

* 43:32 RMID RMID or counter ID in ABMC mode

Quoted 8 lines

resctrl also supports switching between "default" and "mbm_event" mode and there is no support for the number of RMIDs changing between the modes ... this reading an event in "default" mode should support the same number of RMIDs as "mbm_event" mode and we see in __rmid_read_phys() (although, again not enforced) that it supports even fewer bits for RMID

IA32_QM_EVTSEL.RMID (bits 41:32) are configured with valid RMID

Quoted 4 lines

Looks like after this patch there are quite a few different field widths for RMID between what is documented, used directly, and actually enforced.

To add to this it looks like PLZA currently supports 12 bit RMIDs per

	https://lore.kernel.org/lkml/702b88901bc62f07829144a96cc887471b427da8.1787772750.git.babu.moger@amd.com/

I assume this field will also be updated to 15 bits?

The original issue arose when programming a Counter ID wider than 5 bits. To address that issue, the Counter ID width needs to be increased to 12 bits.

Currently, the RMID width is 12 bits, and there is no hardware that supports a width greater than 12 bits.

How about we address the Counter ID issue for now and revisit the RMID width when the specification changes?

Would that work?

Hi Babu,

Quoted 8 lines · Babu

The original issue arose when programming a Counter ID wider than 5 bits. To address that issue, the Counter ID width needs to be increased to 12 bits.

Currently, the RMID width is 12 bits, and there is no hardware that supports a width greater than 12 bits.

How about we address the Counter ID issue for now and revisit the RMID width when the specification changes?

Would that work?

Neither change seems to be reflected in any public spec. The comment in this patch seems to be that the upcoming spec change will cover both?

The AMD64 Architecture Programmer's Manual [1] available at [2] will be updated accordingly in a future revision to document the expanded cntr_id and bw_src field definitions.

If you thus plan to change RMID width when the specification changes then it is not clear to me how the timing is different from the counter ID width change.

In the end it is up to you though since the impact is on AMD hardware that you are best to judge.

Hi Babu,

Quoted 2 lines · Babu Moger

Quoted 1 line · Reinette Chatre

On 9/4/26 11:06 AM, Babu Moger wrote:

...

Quoted 14 lines

Quoted 7 lines

Quoted 6 lines

Fix the issues with the following changes:

1. Update the cntr_id field handling to support the full hardware ABMC counter range and ensure that counter programming does not interfere with unrelated counters.

Quoted 5 lines

Sashiko's assessment that this statement is not accurate looks correct to me.

Looks like the enumeration needs a check to limit the number of supported counters if the hardware supports more than what can be configured? It seems awkward that such hardware could exist and unclear why the spec has a mismatch in

Quoted 8 lines

You're right. The spec overlooked this scenario. I've notified the concerned team.

Do you want me add this check?

-               r->mon.num_mbm_cntrs = (ebx & GENMASK(15, 0)) + 1; +               r->mon.num_mbm_cntrs = (ebx & GENMASK(12, 0)) + 1;

Yes please.

Quoted 10 lines

Quoted 5 lines

the number of bits here. Even if cntr_id expands further to use the remaining reserved bits it would still not be sufficient to configure all the numbers that hardware may claim to support. Are there perhaps more field width changes in this upcoming spec update?

Two fields(ctrl_id and bw_src) in here are changing for this register. I dont know about other changes yet.

Quoted 2 lines

Quoted 2 lines

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

2. Expand the bw_src field to 15 bits.

Do the comments describing the RMID field width when reading the monitoring data (__cntr_id_read() and __rmid_read_phys()) need an update also?

The RMID field width is expected to change. We can revisit this when that happens.

This patch is that change, no? bw_src is expanded to 15 bits, and bw_src contains the RMID.

This is the new RMID field width for monitoring configuration, after configuration the counter needs to be read for the monitoring data via MSR_IA32_QM_EVTSEL and per __cntr_id_read() the RMID field is still restricted (although not enforce by resctrl) to 12 bits:

* 43:32 RMID RMID or counter ID in ABMC mode

resctrl also supports switching between "default" and "mbm_event" mode and there is no support for the number of RMIDs changing between the modes ... this reading an event in "default" mode should support the same number of RMIDs as "mbm_event" mode and we see in __rmid_read_phys() (although, again not enforced) that it supports even fewer bits for RMID

IA32_QM_EVTSEL.RMID (bits 41:32) are configured with valid RMID

Looks like after this patch there are quite a few different field widths for RMID between what is documented, used directly, and actually enforced.

Quoted 6 lines

Quoted 6 lines

Quoted 1 line

3. Change "unsigned long" to u64 to fix truncation on 32-bit x86.

Sashiko found that this change by itself is not sufficient to address issues with 32-bit. What do you think of dropping this part of the patch and instead adding your support to:

Quoted 3 lines

Quoted 1 line

https://lore.kernel.org/lkml/[email protected]/ ?

Yes. I agree and support that approach. Looks like all the maintainers are inline with dropping 32. Will drop this change.

If you do support that change, please consider adding a tag.

resctrl_mbm_assign_mode_write() frees all counters and sets

mbm_assign_on_mkdir for subsequent mkdir, but does not assign counters to groups that already exist, including the default group created at mount. Those events then read "Unassigned" until the user assigns counters by

hand.

Enable mbm_assign_on_mkdir and assign counters to existing CTRL_MON and MON groups with resctrl_assign_cntrs_allrdtgrp() so the switch matches mkdir

auto-assignment. Groups left without a counter still read "Unassigned".

Update Documentation/filesystems/resctrl.rst to describe this.

Fixes 8004ea01cf63 ("fs/resctrl: Introduce the interface to switch between monitor modes")

Signed-off-by Babu Moger <[email protected]>

---
v2: New patch.
This patch addresses the Sashiko comment about documentation issue where counters are not assigned automatically when mode is switched to mbm_event.
https://sashiko.dev/#/patchset/8cb66e18e32e4087a9712c1e68ee6da614efe244.1784322818.git.babu.moger%40amd.com

In fact, it exposed a real issue. When switching to mbm_event mode, existing monitoring groups should be assigned counters whenever counters are available. This provides a smooth transition between modes and aligns the behavior with the existing auto-assignment mechanism.

---
 Documentation/filesystems/resctrl.rst |  7 +++++--
 fs/resctrl/monitor.c                  | 30 ++++++++++++++++++++++++---
 2 files changed, 32 insertions(+), 5 deletions(-)

Documentation/filesystems/resctrl.rst +0 -0

index e4b66af55ffb..79feeb1dc296 100644

Documentation/filesystems/resctrl.rst +0 -0

 	The mode is beneficial for AMD platforms that support more CTRL_MON
 	and MON groups than available hardware counters. By default, this

fs/resctrl/monitor.c +0 -0

index 73413cb128ea..61463741b91b 100644

fs/resctrl/monitor.c +1 -3

+
 /*
  * rdtgroup_free_unassign_cntr() - Unassign and reset the counter ID configuration
  * for the event pointed to by @mevt within the domain @d and resctrl group @rdtgrp.

@@ -1599,9 +1620,6 @@ ssize_t resctrl_mbm_assign_mode_write(struct kernfs_open_file *of, char *buf,
 									   (READS_TO_LOCAL_MEM |
 									    READS_TO_LOCAL_S_MEM |
 									    NON_TEMP_WRITE_TO_LOCAL_MEM);
-		/* Enable auto assignment when switching to "mbm_event" mode */
-		if (enable)
-			r->mon.mbm_assign_on_mkdir = true;
 		/*
 		 * Reset all the non-achitectural RMID state and assignable counters.
 		 */

Hi Babu,

Quoted 1 line · Babu Moger

resctrl_mbm_assign_mode_write() frees all counters and sets

The changelog is easier to read if it documents what the code does instead of documenting the function names. In its current form the reader needs to stop at the first word of this changelog, go to the source code, figure out when resctrl_mbm_assign_mode_write() is called, and then be able to return to changelog to further try and understand the change.

Consider an alternative like:
When the user enables counter assignment mode by writing "mbm_event" to /sys/fs/resctrl/info/L3_MON/mbm_assign_mode resctrl resets all monitoring state and sets ...

Quoted 3 lines

mbm_assign_on_mkdir for subsequent mkdir, but does not assign counters to groups that already exist, including the default group created at mount. Those events then read "Unassigned" until the user assigns counters by

"Those events"? No mention of "events" before this.

Quoted 5 lines

hand.

Enable mbm_assign_on_mkdir and assign counters to existing CTRL_MON and MON groups with resctrl_assign_cntrs_allrdtgrp() so the switch matches mkdir

no need to mention the function name, this can be seen from the patch. Just mention what the change achieves. Looks like "with resctrl_assign_cntrs_allrdtgrp()" can just be dropped.

Quoted 2 lines

auto-assignment. Groups left without a counter still read "Unassigned".

"Groups" -> "An event ..."?
"still read" -> "reads"?

This implies that counters are assigned to all groups but that may not be possible. I am not sure what would be best text here. How about something like:

Enable mbm_assign_on_mkdir and assign counters, while there are some available, to existing ...

Quoted 10 lines

Update Documentation/filesystems/resctrl.rst to describe this.

Fixes 8004ea01cf63 ("fs/resctrl: Introduce the interface to switch between monitor modes")

Signed-off-by Babu Moger <[email protected]>

---
v2: New patch.
This patch addresses the Sashiko comment about documentation issue where counters are not assigned automatically when mode is switched to mbm_event.
https://sashiko.dev/#/patchset/8cb66e18e32e4087a9712c1e68ee6da614efe244.1784322818.git.babu.moger%40amd.com

Sounds like this is needed:

	Reported-by: Sashiko <[email protected]>
	Closes: https://sashiko.dev/#/patchset/8cb66e18e32e4087a9712c1e68ee6da614efe244.1784322818.git.babu.moger%40amd.com

Is this a stable candidate?

Quoted 18 lines

In fact, it exposed a real issue. When switching to mbm_event mode, existing monitoring groups should be assigned counters whenever counters are available. This provides a smooth transition between modes and aligns the behavior with the existing auto-assignment mechanism.

---
  Documentation/filesystems/resctrl.rst |  7 +++++--
  fs/resctrl/monitor.c                  | 30 ++++++++++++++++++++++++---
  2 files changed, 32 insertions(+), 5 deletions(-)

Documentation/filesystems/resctrl.rst +0 -0

index e4b66af55ffb..79feeb1dc296 100644
@@ -371,8 +371,11 @@ with the following files:
  	of counters available is described in the "num_mbm_cntrs" file. Changing the
  	mode may cause all counters on the resource to reset.
 

Documentation/filesystems/resctrl.rst with the following files: · line 375

Quoted 4 lines

Documentation/filesystems/resctrl.rst +2 -2

-	Moving to mbm_event counter assignment mode requires users to assign the counters
-	to the events. Otherwise, the MBM event counters will return 'Unassigned' when read.
+	Moving to mbm_event counter assignment mode enables "mbm_assign_on_mkdir" and
+	assigns counters to the events of all existing groups, including the default

"all existing groups" -> "all existing monitoring groups"

Documentation/filesystems/resctrl.rst with the following files: · line 376

Quoted 2 lines

Documentation/filesystems/resctrl.rst +1 -0

+	group, for as long as counters remain available. Events left without a counter

"for as long as" implies duration. Perhaps "while counters remain available"?

Documentation/filesystems/resctrl.rst with the following files: · line 378

Quoted 3 lines

Documentation/filesystems/resctrl.rst +2 -0

+	will return 'Unassigned' when read until the user assigns one using
+	"mbm_L3_assignments".

hmmm ... guiding users to read each event and use the return value to learn whether a counter is assigned or not seems inefficient. How about replacing last sentence with something similar to the "mbm_assign_on_mkdir" doc:

Consult "mbm_L3_assignments" after switching to "mbm_event" mode for counter assignment states of all monitoring groups.

Quoted 12 lines

Documentation/filesystems/resctrl.rst +0 -0

  	The mode is beneficial for AMD platforms that support more CTRL_MON
  	and MON groups than available hardware counters. By default, this

fs/resctrl/monitor.c +0 -0

index 73413cb128ea..61463741b91b 100644
@@ -1326,6 +1326,27 @@ void rdtgroup_assign_cntrs(struct rdtgroup *rdtgrp)
  					   &mon_event_all[QOS_L3_MBM_LOCAL_EVENT_ID]);
  }
 

fs/resctrl/monitor.c void rdtgroup_assign_cntrs(struct rdtgroup *rdtgrp) · line 1332

Quoted 4 lines

fs/resctrl/monitor.c +4 -0

+/*
+ * resctrl_assign_cntrs_allrdtgrp() - Assign counters to the MBM events of every
+ *				      existing group. Called when "mbm_event" mode
+ *				      is enabled.

Please do not include caller information in function comments. This does not age well and this patch clearly demonstrates this: rdtgroup_assign_cntrs()'s comments read "Called when a new group is created.", after this patch those comments are no longer accurate and thus also needs to change as part of this patch.

fs/resctrl/monitor.c void rdtgroup_assign_cntrs(struct rdtgroup *rdtgrp) · line 1336

Quoted 4 lines

fs/resctrl/monitor.c +4 -0

+ *
+ * Groups created while in "default" mode have no counter assigned, including the
+ * default group created when resctrl is mounted. Assign counters to them so that
+ * enabling the mode leaves the same assignments that mkdir would have made.

Above comment belongs in caller.

fs/resctrl/monitor.c void rdtgroup_assign_cntrs(struct rdtgroup *rdtgrp) · line 1348

Quoted 13 lines

fs/resctrl/monitor.c +12 -0

+ */
+static void resctrl_assign_cntrs_allrdtgrp(void)
+{
+	struct rdtgroup *prgrp, *crgrp;
+
+	list_for_each_entry(prgrp, &rdt_all_groups, rdtgroup_list) {
+		rdtgroup_assign_cntrs(prgrp);
+
+		list_for_each_entry(crgrp, &prgrp->mon.crdtgrp_list, mon.crdtgrp_list)
+			rdtgroup_assign_cntrs(crgrp);
+	}
+}

I think sashiko's feedback about needing to test for pseudo-locked groups need not be followed since there is no overlap between systems supporting assigned counters and those that support pseudo-locking.

Quoted 16 lines

fs/resctrl/monitor.c +1 -3

+
  /*
   * rdtgroup_free_unassign_cntr() - Unassign and reset the counter ID configuration
   * for the event pointed to by @mevt within the domain @d and resctrl group @rdtgrp.

@@ -1599,9 +1620,6 @@ ssize_t resctrl_mbm_assign_mode_write(struct kernfs_open_file *of, char *buf,
  									   (READS_TO_LOCAL_MEM |
  									    READS_TO_LOCAL_S_MEM |
  									    NON_TEMP_WRITE_TO_LOCAL_MEM);
-		/* Enable auto assignment when switching to "mbm_event" mode */
-		if (enable)
-			r->mon.mbm_assign_on_mkdir = true;
  		/*
  		 * Reset all the non-achitectural RMID state and assignable counters.
  		 */

fs/resctrl/monitor.c ssize_t resctrl_mbm_assign_mode_write(struct kernfs_open_file *of, char *buf, · line 1630

Quoted 4 lines

fs/resctrl/monitor.c +1 -0

@@ -1609,6 +1627,12 @@ ssize_t resctrl_mbm_assign_mode_write(struct kernfs_open_file *of, char *buf,
  			mbm_cntr_free_all(r, d);
  			resctrl_reset_rmid_all(r, d);
  		}
+

Comment within the block can be dropped and instead a new comment can be placed here. Something like:

	/*
	 * Counters were freed above, so both new groups (via mkdir) and the
	 * groups that already exist need assignments.
	 */

ABMC ("mbm_event" mode) allows explicit assignment of hardware MBM counters to RMID/event pairs. It is intended for deployments that need to manage counter assignment on platforms where the number of monitoring groups exceeds the available hardware counters. Because hardware MBM counters are scarce, mbm_event mode is best suited for snapshot-and-rotation workflows that monitor a subset of groups at a time.

Commit 0f1576e43adc ("x86/resctrl: Configure mbm_event mode if supported") enabled ABMC automatically during initialization. This causes problems on

systems with limited MBM counters and breaks existing userspace that assumes the historical default mode, including the pqos tool from intel-cmt-cat [1].

For example, pqos mounts resctrl and creates 16 or more monitoring groups, using two counters per group (mbm_local_bytes and mbm_total_bytes). On platforms that provide 32 MBM counters per domain, this consumes the entire counter pool. Additional groups cannot be assigned counters and pqos reports zero bandwidth for them.

Leave mbm_assign_mode in "default" mode during initialization. Default mode can support more monitoring groups (up to 64) than mbm_event mode, which is

typically limited to 16 groups because of hardware counter availability. Common deployments with a modest number of monitoring groups continue to receive accurate bandwidth measurements.

Users that require ABMC functionality can enable it explicitly:

echo mbm_event > /sys/fs/resctrl/info/L3_MON/mbm_assign_mode

Note that default mode has a long-standing limitation when the number of monitoring groups exceeds the available counter pool. After hardware counter reallocation, reads may return "Unavailable" or misleading values. Users that need stable measurements across a large number of monitoring groups should use mbm_event mode and rotate assignments as needed.

Update Documentation/filesystems/resctrl.rst to reflect the default boot behavior, document the limitations of default mode, and adjust mbm_assign_mode examples accordingly.

Signed-off-by Babu Moger <[email protected]>

Link https://github.com/intel/intel-cmt-cat/issues/311 # [1]

---
v2:
Added documentation describing the known issue with the default mode. Will add cc to stable once we have all the things in order. Let me know if I missed anything.

v1:
https://lore.kernel.org/lkml/8cb66e18e32e4087a9712c1e68ee6da614efe244.1784322818.git.babu.moger@amd.com/

---
 Documentation/filesystems/resctrl.rst | 79 +++++++++++++++++----------
 arch/x86/kernel/cpu/resctrl/monitor.c |  1 -
 2 files changed, 49 insertions(+), 31 deletions(-)

Documentation/filesystems/resctrl.rst +5 -7

index 79feeb1dc296..a43ed3c89a93 100644
@@ -355,8 +355,8 @@ with the following files:
 	::
 
 	  # cat /sys/fs/resctrl/info/L3_MON/mbm_assign_mode
-	  [mbm_event]
-	  default
+	  [default]
+	  mbm_event
 
 	"mbm_event":
 

@@ -377,20 +377,30 @@ with the following files:
 	will return 'Unassigned' when read until the user assigns one using
 	"mbm_L3_assignments".
 
-	The mode is beneficial for AMD platforms that support more CTRL_MON
-	and MON groups than available hardware counters. By default, this
-	feature is enabled on AMD platforms with the ABMC (Assignable Bandwidth
-	Monitoring Counters) capability, ensuring counters remain assigned even
-	when the corresponding RMID is not actively used by any processor.
+	The mode is beneficial for AMD platforms that support more CTRL_MON and MON
+	groups than available hardware counters. The mbm_event mode ensures counters
+	remain assigned even when the corresponding RMID is not actively monitored.
 
 	"default":

Documentation/filesystems/resctrl.rst +10 -0

+	capability by writing to the interface.
 
 	"0":
 		Auto assignment is disabled.

@@ -1791,32 +1801,41 @@ a. Check if MBM counter assignment mode is supported.
 
   # mount -t resctrl resctrl /sys/fs/resctrl/
 
+  # cat /sys/fs/resctrl/info/L3_MON/mbm_assign_mode
+  [default]
+  mbm_event
+
+The "mbm_event" and "default" modes are supported. The "default" mode
+is enabled by default.
+
+b. Enable "mbm_event" counter assignment mode.
+::

Hi Babu,

Quoted 7 lines · Babu Moger

ABMC ("mbm_event" mode) allows explicit assignment of hardware MBM counters to RMID/event pairs. It is intended for deployments that need to manage counter assignment on platforms where the number of monitoring groups exceeds the available hardware counters. Because hardware MBM counters are scarce, mbm_event mode is best suited for snapshot-and-rotation workflows that monitor a subset of groups at a time.

Quoted 2 lines

Commit 0f1576e43adc ("x86/resctrl: Configure mbm_event mode if supported") enabled ABMC automatically during initialization. This causes problems on

Se "Fixes:" tag notes in Documentation/process/maintainer-tip.rst

Quoted 4 lines

systems with limited MBM counters and breaks existing userspace that assumes the historical default mode, including the pqos tool from intel-cmt-cat [1].

There is no record of this breaking pqos. *you* created [1] *after* you submitted v1. What a strategy! I mentioned a couple of times that this is

misleading. Since you insist on proclaiming "we cannot break pqos!" as motivation for this change you have to also disclose the consequence of this change on pqos followed by motivation why that is acceptable. Specifically:

	https://lore.kernel.org/lkml/[email protected]/

Quoted 8 lines

For example, pqos mounts resctrl and creates 16 or more monitoring groups, using two counters per group (mbm_local_bytes and mbm_total_bytes). On platforms that provide 32 MBM counters per domain, this consumes the entire counter pool. Additional groups cannot be assigned counters and pqos reports zero bandwidth for them.

Quoted 2 lines

Leave mbm_assign_mode in "default" mode during initialization. Default mode can support more monitoring groups (up to 64) than mbm_event mode, which is

"up to 64" - so it may be fewer than 64? What is guidance to users about how many monitoring groups in "default" mode are "safe"?

Quoted 4 lines

typically limited to 16 groups because of hardware counter availability. Common deployments with a modest number of monitoring groups continue to receive accurate bandwidth measurements.

Please be specific and do not hide the consequences in a note at the end of changelog. For example,
Deployments with 64 or fewer monitoring groups will receive accurate bandwidth measurements. The hardware supports 4096 monitoring groups. Deployments with 65 to 4096 monitoring groups may (without user-visible indication) receive misleading values or "Unavailable".

Users that need stable measurements across 65 or more monitoring groups should use mbm_event mode and rotate assignments as needed.

Although, the earlier text is "up to 64" so above attempt at guidance may not be correct and there is no knowing how many monitoring groups are guaranteed to receive accurate counts?

Quoted 12 lines

Users that require ABMC functionality can enable it explicitly:

echo mbm_event > /sys/fs/resctrl/info/L3_MON/mbm_assign_mode

Note that default mode has a long-standing limitation when the number of monitoring groups exceeds the available counter pool. After hardware counter reallocation, reads may return "Unavailable" or misleading values. Users that need stable measurements across a large number of monitoring groups should use mbm_event mode and rotate assignments as needed.

Quoted 4 lines

Update Documentation/filesystems/resctrl.rst to reflect the default boot behavior, document the limitations of default mode, and adjust mbm_assign_mode examples accordingly.

If the plan is to send this to stable then it needs a "Fixes:" tag.

Quoted 3 lines

Signed-off-by Babu Moger <[email protected]>

Link https://github.com/intel/intel-cmt-cat/issues/311 # [1]

"Link:" -> "Closes:" (and then move it above SoB)?

Quoted 44 lines

---
v2:
Added documentation describing the known issue with the default mode. Will add cc to stable once we have all the things in order. Let me know if I missed anything.

v1:

   https://lore.kernel.org/lkml/8cb66e18e32e4087a9712c1e68ee6da614efe244.1784322818.git.babu.moger@amd.com/
---
  Documentation/filesystems/resctrl.rst | 79 +++++++++++++++++----------
  arch/x86/kernel/cpu/resctrl/monitor.c |  1 -
  2 files changed, 49 insertions(+), 31 deletions(-)

Documentation/filesystems/resctrl.rst +5 -7

index 79feeb1dc296..a43ed3c89a93 100644
@@ -355,8 +355,8 @@ with the following files:
  	::
 
  	  # cat /sys/fs/resctrl/info/L3_MON/mbm_assign_mode
-	  [mbm_event]
-	  default
+	  [default]
+	  mbm_event
 
  	"mbm_event":
 

@@ -377,20 +377,30 @@ with the following files:
  	will return 'Unassigned' when read until the user assigns one using
  	"mbm_L3_assignments".
 
-	The mode is beneficial for AMD platforms that support more CTRL_MON
-	and MON groups than available hardware counters. By default, this
-	feature is enabled on AMD platforms with the ABMC (Assignable Bandwidth
-	Monitoring Counters) capability, ensuring counters remain assigned even
-	when the corresponding RMID is not actively used by any processor.
+	The mode is beneficial for AMD platforms that support more CTRL_MON and MON
+	groups than available hardware counters. The mbm_event mode ensures counters
+	remain assigned even when the corresponding RMID is not actively monitored.
 
  	"default":
 

Documentation/filesystems/resctrl.rst with the following files: · line 389

Quoted 9 lines

Documentation/filesystems/resctrl.rst +3 -5

  	In default mode, resctrl assumes there is a hardware counter for each
-	event within every CTRL_MON and MON group. On AMD platforms, it is
-	recommended to use the mbm_event mode, if supported, to prevent reset of MBM
-	events between reads resulting from hardware re-allocating counters. This can
-	result in misleading values or display "Unavailable" if no counter is assigned
-	to the event.
+	event within every CTRL_MON and MON group. This mode is enabled by default.
+
+	Default mode has a long-standing limitation on AMD platforms that support

Please be specific and drop unnecessary words. For example, "long-standing" can be dropped.

Documentation/filesystems/resctrl.rst with the following files: · line 392

Quoted 4 lines

Documentation/filesystems/resctrl.rst +3 -0

+	more CTRL_MON and MON groups than hardware counters. Hardware dynamically
+	shares a smaller pool of counters among RMIDs. The size of that pool is
+	not enumerated to software (unlike "num_mbm_cntrs" in mbm_event mode), and

I do not think access to "num_mbm_cntrs" depends on mbm_event mode being enabled so "in mbm_event mode" can just be dropped?

Documentation/filesystems/resctrl.rst with the following files: · line 393

Quoted 2 lines

Documentation/filesystems/resctrl.rst +1 -0

+	"num_rmids" may be much larger. On current AMD platforms this pool can

"current AMD platforms" does not age well in documentation. Can "current" just be dropped?

Documentation/filesystems/resctrl.rst with the following files: · line 394

Quoted 2 lines

Documentation/filesystems/resctrl.rst +1 -0

+	provide more counters than mbm_event mode (for example 64, versus 32 ABMC

"ABMC" -> "mbm_event mode"?

There seems to be another distinction that just "more counters": what can be counted by such counter. Specifically, a single counter from from the "pool of 64" seems to count *all* events associated with an RMID, while a single counter from the "pool of 32 mbm_event mode counters" can only count a single event associated with an RMID? This documentation uses the term "counter" interchangeably and is difficult to follow.

Documentation/filesystems/resctrl.rst with the following files: · line 395

Quoted 2 lines

Documentation/filesystems/resctrl.rst +1 -0

+	counters), so more groups can be monitored accurately than with mbm_event.

"mbm_event" -> "mbm_event mode"?

Documentation/filesystems/resctrl.rst with the following files: · line 396

Quoted 2 lines

Documentation/filesystems/resctrl.rst +1 -0

+	Typical usage with fewer groups keeps a counter attached and readings

Drop "Typical usage" and just be specific about the different scenarios. It will be easier for user to determine how their usage matches to specific scenarios than to try and determine if their usage is "typical".

Also related to above text, since resctrl documentation usually refers to counters being assigned to event/group pairs this is not clear about what the counter is attached to.

Documentation/filesystems/resctrl.rst with the following files: · line 397

Quoted 2 lines

Documentation/filesystems/resctrl.rst +1 -0

+	remain accurate. Creating more groups than that pool (for example 64 or

"64" -> "65"?

Documentation/filesystems/resctrl.rst with the following files: · line 399

Quoted 3 lines

Documentation/filesystems/resctrl.rst +2 -0

+	more) can cause hardware to re-allocate counters
+	between reads. Bandwidth values may then be misleading, or reads may return

"between reads" - what reads are referred to here?

Documentation/filesystems/resctrl.rst with the following files: · line 400

Quoted 2 lines

Documentation/filesystems/resctrl.rst +1 -0

+	"Unavailable" if no counter is allocated to the event. There is no

hmmm ... now it is refering to counter being allocated to event, but this seems to be referring to the counters assigned to RMID which would mean it counts all the events?

Documentation/filesystems/resctrl.rst with the following files: · line 402

Quoted 2 lines

Documentation/filesystems/resctrl.rst +2 -0

+	user-visible indication when this begins. Users who need stable readings
+	for many groups should switch to mbm_event mode, if supported, and assign

"many groups" -> "65 or more"?

Since this is not enumerated this may be the best guidance that can be provided ... although since the changelog mentions "up to 64" there really seems no way for users to know how many monitor groups are "safe"?

Quoted 7 lines

Documentation/filesystems/resctrl.rst +1 -0

+	counters to the groups of interest (rotating assignments as needed).
 
  	* To enable "mbm_event" counter assignment mode:
  	  ::

@@ -474,8 +484,8 @@ with the following files:
 

Documentation/filesystems/resctrl.rst with the following files: · line 487

Quoted 5 lines

Documentation/filesystems/resctrl.rst +1 -2

  	Determines if a counter will automatically be assigned to an RMID, MBM event
  	pair when its associated monitor group is created via mkdir. Enabled by default
-	on boot, also when switched from "default" mode to "mbm_event" counter assignment
-	mode. Users can disable this capability by writing to the interface.
+	when switched to "mbm_event" counter assignment mode. Users can disable this

Why is this change necessary? It seems to drop the text that mbm_assign_on_mkdir is enabled on boot ... but it is still enabled on boot, no?

Quoted 28 lines

Documentation/filesystems/resctrl.rst +13 -3

+	capability by writing to the interface.
 
  	"0":
  		Auto assignment is disabled.

@@ -1791,32 +1801,41 @@ a. Check if MBM counter assignment mode is supported.
 
    # mount -t resctrl resctrl /sys/fs/resctrl/
 
+  # cat /sys/fs/resctrl/info/L3_MON/mbm_assign_mode
+  [default]
+  mbm_event
+
+The "mbm_event" and "default" modes are supported. The "default" mode
+is enabled by default.
+
+b. Enable "mbm_event" counter assignment mode.
+::
+
+  # echo "mbm_event" > /sys/fs/resctrl/info/L3_MON/mbm_assign_mode
    # cat /sys/fs/resctrl/info/L3_MON/mbm_assign_mode
    [mbm_event]
    default
 
-The "mbm_event" mode is detected and enabled.
-
-b. Check how many assignable counters are supported.
+c. Check how many assignable counters are supported.

<snip>

So many hunks follow and all they do is relabel the steps. This is a lot of churn for a fix.

What if "step a" instead just drops the

	# mount -t resctrl resctrl /sys/fs/resctrl/
step that implies "mbm_event" is the default?

If so, all these hunks could just be replaced with, for example:

Documentation/filesystems/resctrl.rst +1 -3

index e4b66af55ffb..1c3c27444dd3 100644
@@ -1783,11 +1783,9 @@ View the llc occupancy snapshot::
  Examples on working with mbm_assign_mode
  ========================================
 
-a. Check if MBM counter assignment mode is supported.
+a. Check if MBM counter assignment mode is supported and enabled.
  ::
 
-  # mount -t resctrl resctrl /sys/fs/resctrl/
-
    # cat /sys/fs/resctrl/info/L3_MON/mbm_assign_mode
    [mbm_event]
    default

Quoted 13 lines

arch/x86/kernel/cpu/resctrl/monitor.c +0 -1

index 3838e0a13d36..8a0d6086518b 100644
@@ -471,7 +471,6 @@ int __init rdt_get_l3_mon_config(struct rdt_resource *r)
  		r->mon.mbm_cntr_configurable = true;
  		cpuid_count(0x80000020, 5, &eax, &ebx, &ecx, &edx);
  		r->mon.num_mbm_cntrs = (ebx & GENMASK(15, 0)) + 1;
-		hw_res->mbm_cntr_assign_enabled = true;
  	}
 

arch/x86/kernel/cpu/resctrl/monitor.c int __init rdt_get_l3_mon_config(struct rdt_resource *r) · line 476

Quoted 1 line

arch/x86/kernel/cpu/resctrl/monitor.c +0 -0

  	r->mon_capable = true;

Reinette

Quoted 1 line · Reinette Chatre

On 9/4/26 11:06 AM, Babu Moger wrote:

Quoted 5 lines

Quoted 2 lines

assumes the historical default mode, including the pqos tool from intel-cmt-cat [1].

There is no record of this breaking pqos. *you* created [1] *after* you submitted v1. What a strategy! I mentioned a couple of times that this is

Agreed.

Quoted 4 lines

misleading. Since you insist on proclaiming "we cannot break pqos!" as motivation for this change you have to also disclose the consequence of this change on pqos followed by motivation why that is acceptable. Specifically:

Quoted 1 line

    https://lore.kernel.org/lkml/[email protected]/

I can provide output that demonstrates the issue, where the event counters report zeros. However, we won't observe the large counter values because the hardware resets the counters after reallocation.

Will that be ok?

Quoted 6 lines

Quoted 6 lines

For example, pqos mounts resctrl and creates 16 or more monitoring groups, using two counters per group (mbm_local_bytes and mbm_total_bytes). On platforms that provide 32 MBM counters per domain, this consumes the entire counter pool. Additional groups cannot be assigned counters and pqos reports zero bandwidth for them.

Quoted 5 lines

Quoted 2 lines

Leave mbm_assign_mode in "default" mode during initialization. Default mode can support more monitoring groups (up to 64) than mbm_event mode, which is

"up to 64" - so it may be fewer than 64? What is guidance to users about how many monitoring groups in "default" mode are "safe"?

It is 64. It be more on newer h/w (don't know exact count).

Quoted 4 lines

Although, the earlier text is "up to 64" so above attempt at guidance may not be correct and there is no knowing how many monitoring groups are guaranteed to receive accurate counts?

That is correct. We can get this count by assigning counters iteratively until an "unavailable" response is returned. However, the specification does not mention this behavior.

Quoted 5 lines

Quoted 3 lines

+    remain accurate. Creating more groups than that pool (for example 64 or

"64" -> "65"?

Sure.

Quoted 6 lines

Quoted 4 lines

+    more) can cause hardware to re-allocate counters
+    between reads. Bandwidth values may then be misleading, or reads may return

"between reads" - what reads are referred to here?

"between two event reads" ?

Quoted 9 lines

Quoted 6 lines

(quoted diff) +0 -0

@@ -474,8 +484,8 @@ with the following files:

        Determines if a counter will automatically be assigned to an RMID, MBM event pair when its associated monitor group is created via mkdir. Enabled by default -    on boot, also when switched from "default" mode to "mbm_event" counter assignment -    mode. Users can disable this capability by writing to the interface. +    when switched to "mbm_event" counter assignment mode. Users can disable this

Why is this change necessary? It seems to drop the text that mbm_assign_on_mkdir is enabled on boot ... but it is still enabled on boot, no?

Yes. It is enabled on boot. It should not be set by default. Will update the patch.

Hi Babu,

Quoted 2 lines · Babu Moger

Quoted 1 line · Reinette Chatre

On 9/4/26 11:06 AM, Babu Moger wrote:

...>>> systems with limited MBM counters and breaks existing userspace that

Quoted 12 lines

Quoted 5 lines

Quoted 2 lines

assumes the historical default mode, including the pqos tool from intel-cmt-cat [1].

There is no record of this breaking pqos. *you* created [1] *after* you submitted v1. What a strategy! I mentioned a couple of times that this is

Agreed.

Quoted 4 lines

misleading. Since you insist on proclaiming "we cannot break pqos!" as motivation for this change you have to also disclose the consequence of this change on pqos followed by motivation why that is acceptable. Specifically:

Quoted 5 lines

Quoted 1 line

    https://lore.kernel.org/lkml/[email protected]/

I can provide output that demonstrates the issue, where the event counters report zeros. However, we won't observe the large counter values because the hardware resets the counters after reallocation.

Will that be ok?

No. This is not about hardware resetting the counters. This is about pqos not handling text return values, for example "Unavailable" and "Unassigned". This patch only focuses on pqos treating "Unassigned" as 0, but in "default" mode "Unavailable" will be encountered and pqos treating it as 0 is more severe.

Consider a scenario where a counter is re-assigned. When user space reads the event value then it may see:

<return A>, <return "Unavailable">, <return B (larger than A)>, <return "Unavailable">, ...

"B" is computed by adding the new hardware counter value to A. As you indicate, hardware did reset the counter after re-allocation but that only means that "B" is no longer accurate. "B" is still returned and it is still larger than "A".

Based on above, pqos sees:
A, 0, B, 0, ...

These jumps between bandwidth counts and zero is what pqos perceives as wraparound that is presented in the example:

	https://lore.kernel.org/lkml/[email protected]/

Quoted 10 lines

Quoted 10 lines

Quoted 9 lines

For example, pqos mounts resctrl and creates 16 or more monitoring groups, using two counters per group (mbm_local_bytes and mbm_total_bytes). On platforms that provide 32 MBM counters per domain, this consumes the entire counter pool. Additional groups cannot be assigned counters and pqos reports zero bandwidth for them.

Leave mbm_assign_mode in "default" mode during initialization. Default mode can support more monitoring groups (up to 64) than mbm_event mode, which is

Quoted 4 lines

Quoted 2 lines

"up to 64" - so it may be fewer than 64? What is guidance to users about how many monitoring groups in "default" mode are "safe"?

It is 64. It be more on newer h/w (don't know exact count).

Should it then read "64 or more" instead of "up to 64"?

...

Quoted 5 lines

Quoted 4 lines

Although, the earlier text is "up to 64" so above attempt at guidance may not be correct and there is no knowing how many monitoring groups are guaranteed to receive accurate counts?

Quoted 3 lines

That is correct. We can get this count by assigning counters iteratively until an "unavailable" response is returned. However, the specification does not mention this behavior.

This is about determining the "magic" number of RMIDs, not about counter assignment. User space does not do any counter assignment here. In this case user space can create monitoring groups up to the maximum number of RMIDs supported.

...

Quoted 2 lines

Quoted 2 lines

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

+    remain accurate. Creating more groups than that pool (for example 64 or

"64" -> "65"?

Sure.

This would only be useful if all hardware support the same number of magic RMID though.

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines

+    more) can cause hardware to re-allocate counters
+    between reads. Bandwidth values may then be misleading, or reads may return

Quoted 4 lines

Quoted 1 line

"between reads" - what reads are referred to here?

"between two event reads" ?

This is unclear to me at this point.

...

Quoted 10 lines

Quoted 9 lines

Review with the following files: · line 486

Quoted 6 lines

(quoted diff) +1 -2

@@ -474,8 +484,8 @@ with the following files:
         Determines if a counter will automatically be assigned to an RMID, MBM event
       pair when its associated monitor group is created via mkdir. Enabled by default
-    on boot, also when switched from "default" mode to "mbm_event" counter assignment
-    mode. Users can disable this capability by writing to the interface.
+    when switched to "mbm_event" counter assignment mode. Users can disable this

Why is this change necessary? It seems to drop the text that mbm_assign_on_mkdir is enabled on boot ... but it is still enabled on boot, no?

Quoted 1 line

Yes. It is enabled on boot. It should not be set by default. Will update the patch.

This is about mbm_assign_on_mkdir that *is* set by default, on boot and when switching to "default" mode, no?

Hi Reinette,

Quoted 39 lines · Reinette Chatre

Hi Babu,

Quoted 2 lines · Babu Moger

Quoted 1 line · Reinette Chatre

On 9/4/26 11:06 AM, Babu Moger wrote:

...>>> systems with limited MBM counters and breaks existing userspace that

Quoted 12 lines

Quoted 5 lines

Quoted 2 lines

assumes the historical default mode, including the pqos tool from intel-cmt-cat [1].

There is no record of this breaking pqos. *you* created [1] *after* you submitted v1. What a strategy! I mentioned a couple of times that this is

Agreed.

Quoted 4 lines

misleading. Since you insist on proclaiming "we cannot break pqos!" as motivation for this change you have to also disclose the consequence of this change on pqos followed by motivation why that is acceptable. Specifically:

Quoted 5 lines

Quoted 1 line

     https://lore.kernel.org/lkml/77f77d02-fae7-401d-9bb5- [email protected]/

I can provide output that demonstrates the issue, where the event counters report zeros. However, we won't observe the large counter values because the hardware resets the counters after reallocation.

Will that be ok?

No. This is not about hardware resetting the counters. This is about pqos not handling text return values, for example "Unavailable" and "Unassigned". This patch only focuses on pqos treating "Unassigned" as 0, but in "default" mode "Unavailable" will be encountered and pqos treating it as 0 is more severe.

Consider a scenario where a counter is re-assigned. When user space reads the event value then it may see:

<return A>, <return "Unavailable">, <return B (larger than A)>, <return "Unavailable">, ...

"B" is computed by adding the new hardware counter value to A. As you indicate, hardware did reset the counter after re-allocation but that only means that "B" is no longer accurate. "B" is still returned and it is still larger than "A".

Quoted 7 lines

Based on above, pqos sees:
A, 0, B, 0, ...

These jumps between bandwidth counts and zero is what pqos perceives as wraparound that is presented in the example:

    https://lore.kernel.org/lkml/77f77d02-fae7-401d-9bb5- [email protected]/

Got it. I can add the output of the issue. Something like this.

TIME 2026-09-15 00:53:46
CORE     IPC      MISSES     LLC[KB]   MBL[MB/s]   MBR[MB/s] 0        0.76         60k        32.0         0.0         0.0 1        0.45          1k        32.0         0.0         0.0 2        1.57        107k        64.0         0.0 17592186044184.9 3        1.62        276k      4928.0         3.2         0.5 4        0.53          1k       160.0         0.0         0.0 5        0.63         39k      1664.0         0.2         0.0 6        0.44          6k       128.0         0.0         0.0 7        0.50          1k       320.0         0.0         0.0

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 9 lines

For example, pqos mounts resctrl and creates 16 or more monitoring groups, using two counters per group (mbm_local_bytes and mbm_total_bytes). On platforms that provide 32 MBM counters per domain, this consumes the entire counter pool. Additional groups cannot be assigned counters and pqos reports zero bandwidth for them.

Leave mbm_assign_mode in "default" mode during initialization. Default mode can support more monitoring groups (up to 64) than mbm_event mode, which is

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

"up to 64" - so it may be fewer than 64? What is guidance to users about how many monitoring groups in "default" mode are "safe"?

It is 64. It be more on newer h/w (don't know exact count).

Should it then read "64 or more" instead of "up to 64"?

Sure.

Quoted 8 lines

...

Quoted 5 lines

Quoted 4 lines

Although, the earlier text is "up to 64" so above attempt at guidance may not be correct and there is no knowing how many monitoring groups are guaranteed to receive accurate counts?

Quoted 7 lines

Quoted 3 lines

That is correct. We can get this count by assigning counters iteratively until an "unavailable" response is returned. However, the specification does not mention this behavior.

This is about determining the "magic" number of RMIDs, not about counter assignment. User space does not do any counter assignment here. In this case user space can create monitoring groups up to the maximum number of RMIDs supported.

Little bit confused here. How about we revisit this text again in v3?

Quoted 8 lines

...

Quoted 5 lines

Quoted 5 lines

Quoted 4 lines

+    remain accurate. Creating more groups than that pool (for example 64 or

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

"64" -> "65"?

Sure.

This would only be useful if all hardware support the same number of magic RMID though.

It

Quoted 48 lines · Babu

Quoted 37 lines · Reinette Chatre

Quoted 2 lines · Babu Moger

Quoted 1 line · Reinette Chatre

On 9/4/26 11:06 AM, Babu Moger wrote:

...>>> systems with limited MBM counters and breaks existing userspace that

Quoted 12 lines

Quoted 5 lines

Quoted 2 lines

assumes the historical default mode, including the pqos tool from intel-cmt-cat [1].

There is no record of this breaking pqos. *you* created [1] *after* you submitted v1. What a strategy! I mentioned a couple of times that this is

Agreed.

Quoted 4 lines

misleading. Since you insist on proclaiming "we cannot break pqos!" as motivation for this change you have to also disclose the consequence of this change on pqos followed by motivation why that is acceptable. Specifically:

Quoted 5 lines

Quoted 1 line

     https://lore.kernel.org/lkml/77f77d02-fae7-401d-9bb5- [email protected]/

I can provide output that demonstrates the issue, where the event counters report zeros. However, we won't observe the large counter values because the hardware resets the counters after reallocation.

Will that be ok?

No. This is not about hardware resetting the counters. This is about pqos not handling text return values, for example "Unavailable" and "Unassigned". This patch only focuses on pqos treating "Unassigned" as 0, but in "default" mode "Unavailable" will be encountered and pqos treating it as 0 is more severe.

Consider a scenario where a counter is re-assigned. When user space reads the event value then it may see:

<return A>, <return "Unavailable">, <return B (larger than A)>, <return "Unavailable">, ...

"B" is computed by adding the new hardware counter value to A. As you indicate, hardware did reset the counter after re-allocation but that only means that "B" is no longer accurate. "B" is still returned and it is still larger than "A".

Quoted 7 lines

Based on above, pqos sees:
A, 0, B, 0, ...

These jumps between bandwidth counts and zero is what pqos perceives as wraparound that is presented in the example:

    https://lore.kernel.org/lkml/77f77d02-fae7-401d-9bb5- [email protected]/

Got it. I can add the output of the issue. Something like this.

Quoted 10 lines

TIME 2026-09-15 00:53:46
CORE     IPC      MISSES     LLC[KB]   MBL[MB/s]   MBR[MB/s] 0        0.76         60k        32.0         0.0         0.0 1        0.45          1k        32.0         0.0         0.0 2        1.57        107k        64.0         0.0 17592186044184.9 3        1.62        276k      4928.0         3.2         0.5 4        0.53          1k       160.0         0.0         0.0 5        0.63         39k      1664.0         0.2         0.0 6        0.44          6k       128.0         0.0         0.0 7        0.50          1k       320.0         0.0         0.0

Quoted 8 lines

Quoted 8 lines

Quoted 7 lines

Quoted 3 lines

Although, the earlier text is "up to 64" so above attempt at guidance may not be correct and there is no knowing how many monitoring groups are guaranteed to receive accurate counts?

That is correct. We can get this count by assigning counters iteratively until an "unavailable" response is returned. However, the specification does not mention this behavior.

Quoted 5 lines

Quoted 3 lines

This is about determining the "magic" number of RMIDs, not about counter assignment. User space does not do any counter assignment here. In this case user space can create monitoring groups up to the maximum number of RMIDs supported.

Little bit confused here. How about we revisit this text again in v3?

Quoted 4 lines

Quoted 2 lines

This would only be useful if all hardware support the same number of magic RMID though.

It

Sorry. Response cut short.

How about we revisit in v3?

Hi Babu,

Quoted 49 lines · Babu Moger

Quoted 48 lines · Babu

Quoted 37 lines · Reinette Chatre

Quoted 2 lines · Babu Moger

Quoted 1 line · Reinette Chatre

On 9/4/26 11:06 AM, Babu Moger wrote:

...>>> systems with limited MBM counters and breaks existing userspace that

Quoted 12 lines

Quoted 5 lines

Quoted 2 lines

assumes the historical default mode, including the pqos tool from intel-cmt-cat [1].

There is no record of this breaking pqos. *you* created [1] *after* you submitted v1. What a strategy! I mentioned a couple of times that this is

Agreed.

Quoted 4 lines

misleading. Since you insist on proclaiming "we cannot break pqos!" as motivation for this change you have to also disclose the consequence of this change on pqos followed by motivation why that is acceptable. Specifically:

Quoted 5 lines

Quoted 1 line

     https://lore.kernel.org/lkml/77f77d02-fae7-401d-9bb5- [email protected]/

I can provide output that demonstrates the issue, where the event counters report zeros. However, we won't observe the large counter values because the hardware resets the counters after reallocation.

Will that be ok?

No. This is not about hardware resetting the counters. This is about pqos not handling text return values, for example "Unavailable" and "Unassigned". This patch only focuses on pqos treating "Unassigned" as 0, but in "default" mode "Unavailable" will be encountered and pqos treating it as 0 is more severe.

Consider a scenario where a counter is re-assigned. When user space reads the event value then it may see:

<return A>, <return "Unavailable">, <return B (larger than A)>, <return "Unavailable">, ...

"B" is computed by adding the new hardware counter value to A. As you indicate, hardware did reset the counter after re-allocation but that only means that "B" is no longer accurate. "B" is still returned and it is still larger than "A".

Quoted 7 lines

Based on above, pqos sees:
A, 0, B, 0, ...

These jumps between bandwidth counts and zero is what pqos perceives as wraparound that is presented in the example:

    https://lore.kernel.org/lkml/77f77d02-fae7-401d-9bb5- [email protected]/

Got it. I can add the output of the issue. Something like this.

Quoted 10 lines

Quoted 10 lines

TIME 2026-09-15 00:53:46
CORE     IPC      MISSES     LLC[KB]   MBL[MB/s]   MBR[MB/s] 0        0.76         60k        32.0         0.0         0.0 1        0.45          1k        32.0         0.0         0.0 2        1.57        107k        64.0         0.0 17592186044184.9 3        1.62        276k      4928.0         3.2         0.5 4        0.53          1k       160.0         0.0         0.0 5        0.63         39k      1664.0         0.2         0.0 6        0.44          6k       128.0         0.0         0.0 7        0.50          1k       320.0         0.0         0.0

This would demonstrate how the change impacts pqos. Since the spirit of the changelog continues to be "resctrl should not break pqos" it should motivate why incorrect wraparound like above is more acceptable than returning 0 MB/s when counters are not assigned.