linux-kernel - Re: [RFC PATCH 04/19] fs/resctrl: Add the documentation for Global Memory Bandwidth Allocation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b815f822-83e7-4ab5-8464-7f53485ba362@amd.com>
Date: Tue, 10 Feb 2026 13:44:14 -0600
From: Babu Moger <babu.moger@....com>
To: Reinette Chatre <reinette.chatre@...el.com>, Babu Moger <bmoger@....com>,
 "Luck, Tony" <tony.luck@...el.com>
Cc: corbet@....net, Dave.Martin@....com, james.morse@....com,
 tglx@...nel.org, mingo@...hat.com, bp@...en8.de,
 dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com,
 peterz@...radead.org, juri.lelli@...hat.com, vincent.guittot@...aro.org,
 dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
 mgorman@...e.de, vschneid@...hat.com, akpm@...ux-foundation.org,
 pawan.kumar.gupta@...ux.intel.com, pmladek@...e.com,
 feng.tang@...ux.alibaba.com, kees@...nel.org, arnd@...db.de,
 fvdl@...gle.com, lirongqing@...du.com, bhelgaas@...gle.com,
 seanjc@...gle.com, xin@...or.com, manali.shukla@....com,
 dapeng1.mi@...ux.intel.com, chang.seok.bae@...el.com,
 mario.limonciello@....com, naveen@...nel.org, elena.reshetova@...el.com,
 thomas.lendacky@....com, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org, kvm@...r.kernel.org, peternewman@...gle.com,
 eranian@...gle.com, gautham.shenoy@....com
Subject: Re: [RFC PATCH 04/19] fs/resctrl: Add the documentation for Global
 Memory Bandwidth Allocation

Hi Reinette,

On 2/9/26 10:32, Reinette Chatre wrote:
> Hi Babu and Tony,
>
> On 2/3/26 8:38 AM, Babu Moger wrote:
>> Hi Tony,
>>
>> On 2/2/26 18:00, Luck, Tony wrote:
>>> On Wed, Jan 21, 2026 at 03:12:42PM -0600, Babu Moger wrote:
>>>> +Global Memory bandwidth Allocation
>>>> +-----------------------------------
>>>> +
>>>> +AMD hardware supports Global Memory Bandwidth Allocation (GMBA) provides
>>>> +a mechanism for software to specify bandwidth limits for groups of threads
>>>> +that span across multiple QoS domains. This collection of QOS domains is
>>>> +referred to as GMBA control domain. The GMBA control domain is created by
>>>> +setting the same GMBA limits in one or more QoS domains. Setting the default
>>>> +max_bandwidth excludes the QoS domain from being part of GMBA control domain.
>>> I don't see any checks that the user sets the *SAME* GMBA limits.
>>>
>>> What happens if the user ignores the dosumentation and sets different
>>> limits?
>> Good point. Adding checks could be challenging when users update each schema individually with different values. We don't know which one value is the one he is intending to keep.
>>
>>> ... snip ...
>>>
>>> +  # cat schemata
>>> +    GMB:0=2048;1=2048;2=2048;3=2048
>>> +     MB:0=4096;1=4096;2=4096;3=4096
>>> +     L3:0=ffff;1=ffff;2=ffff;3=ffff
>>> +
>>> +  # echo "GMB:0=8;2=8" > schemata
>>> +  # cat schemata
>>> +    GMB:0=   8;1=2048;2=   8;3=2048
>>> +     MB:0=4096;1=4096;2=4096;3=4096
>>> +     L3:0=ffff;1=ffff;2=ffff;3=ffff
>>>
>>> Can the user go on to set:
>>>
>>>      # echo "GMB:1=10;3=10" > schemata
>>>
>>> and have domains 0 & 2 with a combined 8GB limit,
>>> while domains 1 & 3 run with a combined 10GB limit?
>>> Or is there a single "GMBA domain"?
>> In that case, it  is still treated as a single GMBA domain, but the behavior becomes unpredictable. The hardware expert mentioned that it will default to the lowest value among all inputs in this case, 8GB.
>>
>>
>>> Will using "2048" as the "this domain isn't limited
>>> by GMBA" value come back to haunt you when some
>>> system has much more than 2TB bandwidth to divide up?
>> It is actually 4096 (4TB). I made a mistake in the example.  I am assuming it may not an issue in the current generation.
>>
>> It is expected to go up in next generation.
>>
>> GMB:0=4096;1=4096;2=4096;3=4096;
>>     MB:0=8192;1=8192;2=8192;3=8192;
>>      L3:0=ffff;1=ffff;2=ffff;3=ffff
>>
>>
>>> Should resctrl have a non-numeric "unlimited" value
>>> in the schemata file for this?
>> The value 4096 corresponds to 12th bit set.  It is called U-bit. If the U bit is set then that domain is not part of the GMBA domain.
>>
>> I was thinking of displaying the "U" in those cases.  It may be good idea to do something like this.
>>
>> GMB:0=      8;1=      U;2=     8 ;3=      U;
>>     MB:0=8192;1=8192;2=8192;3=8192;
>>      L3:0=ffff;1=ffff;2=ffff;3=ffff
>>
>>
>>> The "mba_MBps" feature used U32_MAX as the unlimited
>>> value. But it looks somewhat ugly in the schemata
>>> file:
>> Yes, I agree. Non-numeric would have been better.
> How would such a value be described in a generic way as part of the new schema
> description format?


I dont think we need any special handling.  We should report the actual 
numeric value for max in new format.

> Since the proposed format contains a maximum I think just using that
> value may be simplest while matching what is currently displayed for
> "unlimited" MB, no?
>
Yea.  I t should be ok to display the max value here.

Thanks

Babu