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

[Reinette Chatre <reinette.chatre@intel.com>]

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?

> 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? 
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"
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?

Reinette

[1] https://lore.kernel.org/lkml/fb1e2686-237b-4536-acd6-15159abafcba@intel.com/