Re: [RFC PATCH 01/19] x86,fs/resctrl: Add support for Global Bandwidth Enforcement (GLBE)

[Moger, Babu]

Hi Reinette,


On 2/9/2026 12:44 PM, Reinette Chatre wrote:
> Hi Babu,
>
> On 1/21/26 1:12 PM, Babu Moger wrote:
> > On AMD systems, the existing MBA feature allows the user to set a bandwidth
> > limit for each QOS domain. However, multiple QOS domains share system
> > memory bandwidth as a resource. In order to ensure that system memory
> > bandwidth is not over-utilized, user must statically partition the
> > available system bandwidth between the active QOS domains. This typically
>
> How do you define "active" QoS Domain?

Some domains may not have any CPUs associated with that CLOSID. Active 
meant, I'm referring to domains that have CPUs assigned to the CLOSID.

> > results in system memory being under-utilized since not all QOS domains are
> > using their full bandwidth Allocation.
> >
> > AMD PQoS Global Bandwidth Enforcement(GLBE) provides a mechanism
> > for software to specify bandwidth limits for groups of threads that span
> > multiple QoS Domains. This collection of QOS domains is referred to as GLBE
> > control domain. The GLBE ceiling sets a maximum limit on a memory bandwidth
> > in GLBE control domain. Bandwidth is shared by all threads in a Class of
> > Service(COS) across every QoS domain managed by the GLBE control domain.
>
> How does this bandwidth allocation limit impact existing MBA? For example, if a
> system has two domains (A and B) that user space separately sets MBA
> allocations for while also placing both domains within a "GLBE control domain"
> with a different allocation, does the individual MBA allocations still matter?

Yes. Both ceilings are enforced at their respective levels.
The MBA ceiling is applied at the QoS domain level.
The GLBE ceiling is applied at the GLBE control  domain level.
If the MBA ceiling exceeds the GLBE ceiling, the effective MBA limit 
will be capped by the GLBE ceiling.

> > From the description it sounds as though there is a new "memory bandwidth
> ceiling/limit" that seems to imply that MBA allocations are limited by
> GMBA allocations while the proposed user interface present them as independent.
>
> If there is indeed some dependency here ... while MBA and GMBA CLOSID are
> enumerated separately, under which scenario will GMBA and MBA support different
> CLOSID? As I mentioned in [1] from user space perspective "memory bandwidth"

I can see the following scenarios where MBA and GMBA can operate 
independently:
1. If the GMBA limit is set to ‘unlimited’, then MBA functions as an 
independent CLOS.
2. If the MBA limit is set to ‘unlimited’, then GMBA functions as an 
independent CLOS.
I hope this clarifies your question.


> can be seen as a single "resource" that can be allocated differently based on
> the various schemata associated with that resource. This currently has a
> dependency on the various schemata supporting the same number of CLOSID which
> may be something that we can reconsider?

After reviewing the new proposal again, I’m still unsure how all the 
pieces will fit together. MBA and GMBA share the same scope and have 
inter-dependencies. Without the full implementation details, it’s 
difficult for me to provide meaningful feedback on new approach.

Thanks
Babu