mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Reinette Chatre <reinette.chatre@intel.com>
To: Ben Horgan <ben.horgan@arm.com>, Fenghua Yu <fenghuay@nvidia.com>,
	"Tony Luck" <tony.luck@intel.com>,
	James Morse <james.morse@arm.com>,
	Dave Martin <Dave.Martin@arm.com>,
	Babu Moger <babu.moger@amd.com>,
	Drew Fustini <fustini@kernel.org>, Chen Yu <yu.c.chen@intel.com>
Cc: Borislav Petkov <bp@alien8.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	Peter Newman <peternewman@google.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] mpam,x86,fs/resctrl: Generic schema description Proof of Concept
Date: Thu, 16 Jul 2026 09:04:19 -0700	[thread overview]
Message-ID: <44f26cd4-be79-476e-b002-7ccfb7705179@intel.com> (raw)
In-Reply-To: <57740b97-80ee-4632-bca3-dc43cd7776c2@arm.com>

Hi Ben, Chenyu, and Tony,

On 7/16/26 7:59 AM, Ben Horgan wrote:
> On 7/15/26 16:41, Reinette Chatre wrote:
>> On 7/15/26 1:34 AM, Ben Horgan wrote:
>>> On 7/14/26 23:06, Reinette Chatre wrote:

...

>>>> Beyond this I believe that MPAM currently emulates the MB control with its "MB_MAX" control and users may want
>>>> to make bandwidth allocations at the fine granularity that it supports. Taking this into account the interface
>>>> may end up looking like:
>>>>
>>>> info/
>>>> └── MB/
>>>>     └── resource_schemata/
>>>>         ├── MB/
>>>>         │   ├── MB_MAX/
>>>>         │   │   └── scope:L3
>>>>         │   └── scope:L3
>>>>         └── MB_NODE/
>>>>             └── scope:NODE
>>>>
>>>> A system like above will thus have three schemata file entries:
>>>> MB
>>>> MB_MAX
>>>> MB_NODE
>>>>
>>>> Three schemata file entries would be unnecessary for users familiar with the finer granularity MB_MAX control
>>>> so that is where the "mode" file can be used to disable the legacy MB control to just expose MB_MAX and MB_NODE
>>>> on these systems.
>>>>> Would that work for these systems?
>>>
>>> I'm not clear on the behaviour when the schemata file contains both MB and MB_MAX entries. I assume
>>> we should expect that the user might read back the whole file, modify what they expect to change and
>>> then write everything back. If legacy software does this and wants to change the MB schemata then
>>> the MB and MB_MAX values would be incompatible. Will we just ignore values that haven't changed and
>>> fail the write if two dependent schemata are changed at the same time?
>>
>> An alternative would be to follow Dave Martin's suggestion to prefix emulated controls in schemata file
>> with "#":
>> https://lore.kernel.org/lkml/aNv53UmFGDBL0z3O@e133380.arm.com/
> 
> I was aware of this but I had (mis)thought that the "mode" file was the alternative to this that was
> being taken forward.
> 
>> This was one element of original discussion that fizzled a bit since it was not obvious that user
>> space would behave like this. Consider, for example, from Documentation/filesystems/resctrl.rst:
>>
>> 	Reading/writing the schemata file
>> 	---------------------------------
>> 	... When writing you only need to specify those values which you wish to change. ..
> 
> Yeah, I don't know but it does seem like something a user could reasonably expect to work.

ok. 

>>> Alternatively, could the "mode" file be used to switch between "MB" and "MB_MAX" and the two never
>>> need be shown at the same time. The user opts in to using the new interface, "MB_MAX" by setting
>>> "mode" and can just toggle back if they want to use "MB" directly again.
>> Interesting. So far the "mode" options have been "legacy" and "native" where "legacy" would show the
>> legacy as well as emulated controls in the schemata file and "native" will only show the new controls.
>> resctrl could make the default of "legacy" mean that *only* the legacy control is shown without insight
>> into the controls it is being emulated with. The only insight to this would continue to be via the
>> hierarchy in the info directory, which would show relationship but not the actual control values.
>> Do you think there could be a need for users (excluding validation?) that may want to see the underlying
>> control values used to emulate a legacy control?
> 
> They may want to see the underlying values to be able to migrate there legacy configuration to the
> native configuration but they can just write their legacy configuration and then toggle the mode to
> see the values in the native mode.
> 
>>
>> I assume for backward compatibility that "legacy" would remain the default so a possible inconvenience
>> here would be that users familiar with the new controls would forever need to switch the mode before being
>> able to use them.
> 
> This does also make the new controls slightly harder to discover.
> 
What if resctrl combines the two suggestions? Specifically, for backward compatibility the mode will be
"legacy" and if there are emulated controls then resctrl displays them in schemata file with "#" prefix
but not(*) support any changes from user space to the underlying hardware controls. This will make new controls
easier to discover and let user space see the underlying values, but not break a user space that
may read schemata file, change a few values, and write entire file back.

How the "enabled" vs "disabled" state of a control works with this needs some confirmation since region-aware
MBA support has this extra caveat of supporting MSR and ACPI interfaces which results in the relationship
between "mode" and "status" of underlying controls not being consistent. This may be ok but please consider
example below.

Thinking through this with examples as I understand MPAM and RDT region aware so far. Could this work for
MPAM and region aware MBA?

(*) Should resctrl allow user space to change underlying control value of an emulated control in "legacy" mode?

MPAM
====
1) System default

info hierarchy
--------------
info/
└── MB/
    └── schemata/
        ├── MB/
        │   ├── MB_MAX/
        │   │   └── status:enabled
        │   └── status:enabled
        └── mode:[legacy] native

schemata file
-------------
MB:...
# MB_MAX:...

- In above, user space attempting to change MB_MAX via schemata file with or without "#" prefix will have no effect.
  TBD: there should not be obstacles to resctrl supporting user space changes by removing the "#" prefix.
- MB_MAX control values would show the current active control values of MB_MAX control used to emulate the MB control

2) User space switches to fine grained controls

# echo "native" > /sys/fs/resctrl/info/MB/schemata/mode

info hierarchy
--------------
info/
└── MB/
    └── schemata/
        ├── MB/
        │   ├── MB_MAX/
        │   │   └── status:enabled
        │   └── status:disabled
        └── mode:legacy [native]

schemata file
-------------
MB_MAX:...

- Legacy control not displayed at all
- no # prefix

RDT region aware when using MSR interface for legacy controls
=============================================================
1) System default

info hierarchy
--------------
info/
└── MB/
    └── schemata/
        ├── MB/
        │   ├── MB_REGION0_MAX/
        │   │   └── status:disabled
        │   ├── MB_REGION1_MAX/
        │   │   └── status:disabled
        │   ├── MB_REGION2_MAX/
        │   │   └── status:disabled
        │   ├── MB_REGION3_MAX/
        │   │   └── status:disabled
        │   └── status:enabled
        └── mode:[legacy] native

schemata file
-------------
MB:...

2) User space switches to fine grained controls

# echo "native" > /sys/fs/resctrl/info/MB/schemata/mode

info hierarchy
--------------
info/
└── MB/
    └── schemata/
        ├── MB/
        │   ├── MB_REGION0_MAX/
        │   │   └── status:enabled
        │   ├── MB_REGION1_MAX/
        │   │   └── status:enabled
        │   ├── MB_REGION2_MAX/
        │   │   └── status:enabled
        │   ├── MB_REGION3_MAX/
        │   │   └── status:enabled
        │   └── status:disabled
        └── mode:legacy [native]

schemata file
-------------
MB_REGION0_MAX:...
MB_REGION1_MAX:...
MB_REGION2_MAX:...
MB_REGION3_MAX:...


RDT region aware when using ACPI interface for legacy controls
=============================================================
1) System default

info hierarchy
--------------
info/
└── MB/
    └── schemata/
        ├── MB/
        │   ├── MB_REGION0_MAX/
        │   │   └── status:enabled
        │   ├── MB_REGION1_MAX/
        │   │   └── status:enabled
        │   ├── MB_REGION2_MAX/
        │   │   └── status:enabled
        │   ├── MB_REGION3_MAX/
        │   │   └── status:enabled
        │   └── status:enabled
        └── mode:[legacy] native

schemata file
-------------
MB:...
# MB_REGION0_MAX:...
# MB_REGION1_MAX:...
# MB_REGION2_MAX:...
# MB_REGION3_MAX:...

2) User space switches to fine grained controls

# echo "native" > /sys/fs/resctrl/info/MB/schemata/mode

info hierarchy
--------------
info/
└── MB/
    └── schemata/
        ├── MB/
        │   ├── MB_REGION0_MAX/
        │   │   └── status:enabled
        │   ├── MB_REGION1_MAX/
        │   │   └── status:enabled
        │   ├── MB_REGION2_MAX/
        │   │   └── status:enabled
        │   ├── MB_REGION3_MAX/
        │   │   └── status:enabled
        │   └── status:disabled
        └── mode:legacy [native]

schemata file
-------------
MB_REGION0_MAX:...
MB_REGION1_MAX:...
MB_REGION2_MAX:...
MB_REGION3_MAX:...

Reinette

  parent reply	other threads:[~2026-07-16 16:04 UTC|newest]

Thread overview: 84+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-29 18:06 Reinette Chatre
2026-06-02 20:23 ` Babu Moger
2026-06-02 22:56   ` Reinette Chatre
2026-06-03  1:14     ` Moger, Babu
2026-06-03  3:55       ` Reinette Chatre
2026-06-03 14:40         ` Babu Moger
2026-06-02 23:32 ` Chen, Yu C
2026-06-03  3:45   ` Reinette Chatre
2026-06-03 11:53     ` Chen, Yu C
2026-06-04 16:37       ` Reinette Chatre
2026-06-05 15:43         ` Chen, Yu C
2026-06-05 16:20           ` Reinette Chatre
2026-06-03 15:15 ` Ben Horgan
2026-06-03 19:34   ` Drew Fustini
2026-06-04 11:24     ` Ben Horgan
2026-06-04 17:38       ` Drew Fustini
2026-06-12  1:30         ` Shaopeng Tan (Fujitsu)
2026-06-17 15:29           ` Reinette Chatre
2026-06-19  1:42             ` Shaopeng Tan (Fujitsu)
2026-06-22 16:10               ` Reinette Chatre
2026-06-23  5:04                 ` Shaopeng Tan (Fujitsu)
2026-06-04 21:05     ` Reinette Chatre
2026-06-05 19:35       ` Drew Fustini
2026-06-06  5:10         ` Drew Fustini
2026-06-06  5:23           ` Drew Fustini
2026-06-04 17:43   ` Reinette Chatre
2026-06-05 14:53     ` Ben Horgan
2026-06-05 15:39       ` Reinette Chatre
2026-06-05 16:37         ` Ben Horgan
2026-06-08 16:16           ` Reinette Chatre
2026-06-09 10:10             ` Ben Horgan
2026-06-09 15:28               ` Reinette Chatre
2026-06-09 16:37                 ` Ben Horgan
2026-06-09 17:41                   ` Reinette Chatre
2026-06-10  7:09                     ` Chen, Yu C
2026-06-10 14:27                       ` Chen, Yu C
2026-06-10 16:13                         ` Reinette Chatre
2026-06-10 17:57                           ` Chen, Yu C
2026-06-10 18:10                             ` Reinette Chatre
2026-06-10 15:59                       ` Reinette Chatre
2026-06-10 18:05                         ` Chen, Yu C
2026-06-11  3:26                         ` Chen, Yu C
2026-06-11 15:45                           ` Reinette Chatre
2026-06-26 15:46                             ` Chen, Yu C
2026-07-02 14:27                               ` Ben Horgan
2026-07-03  9:01                                 ` Chen, Yu C
2026-07-14 21:37                               ` Reinette Chatre
2026-07-15  2:49                                 ` Chen, Yu C
2026-06-10  4:31                 ` Drew Fustini
2026-06-10 15:14                   ` Reinette Chatre
2026-06-03 18:46 ` Luck, Tony
2026-06-04 10:02   ` Ben Horgan
2026-06-04 21:42   ` Reinette Chatre
2026-07-08 12:56     ` Chen, Yu C
2026-07-14 21:39       ` Reinette Chatre
2026-06-03 22:14 ` Drew Fustini
2026-06-04 21:47   ` Reinette Chatre
2026-06-05 19:48     ` Drew Fustini
2026-06-15 21:05 ` Moger, Babu
2026-06-17 17:18   ` Reinette Chatre
2026-06-17 20:29     ` Babu Moger
2026-06-24 19:08 ` Fenghua Yu
2026-06-24 22:22   ` Reinette Chatre
2026-06-25  1:26     ` Fenghua Yu
2026-06-25 15:43       ` Reinette Chatre
2026-07-10 20:59         ` Fenghua Yu
2026-07-14 22:06           ` Reinette Chatre
2026-07-15  8:34             ` Ben Horgan
2026-07-15 15:41               ` Reinette Chatre
2026-07-16 14:59                 ` Ben Horgan
2026-07-16 16:02                   ` Luck, Tony
2026-07-16 16:22                     ` Ben Horgan
2026-07-16 17:50                       ` Reinette Chatre
2026-07-17 10:27                         ` Ben Horgan
2026-07-16 16:04                   ` Reinette Chatre [this message]
2026-07-16 16:44                     ` Ben Horgan
2026-07-16 17:07                       ` Reinette Chatre
2026-07-17 12:20                         ` Ben Horgan
2026-07-17 16:00                           ` Reinette Chatre
2026-07-17 16:02                     ` Chen, Yu C
2026-07-17 16:55                       ` Reinette Chatre
2026-07-02 13:37       ` Ben Horgan
2026-07-02 15:16         ` Fenghua Yu
2026-07-03 13:42           ` Ben Horgan

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=44f26cd4-be79-476e-b002-7ccfb7705179@intel.com \
    --to=reinette.chatre@intel.com \
    --cc=Dave.Martin@arm.com \
    --cc=babu.moger@amd.com \
    --cc=ben.horgan@arm.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=fenghuay@nvidia.com \
    --cc=fustini@kernel.org \
    --cc=james.morse@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peternewman@google.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    --cc=yu.c.chen@intel.com \
    /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