From: "Chen, Yu C" <yu.c.chen@intel.com>
To: Reinette Chatre <reinette.chatre@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>,
Ben Horgan <ben.horgan@arm.com>,
James Morse <james.morse@arm.com>,
Fenghua Yu <fenghuay@nvidia.com>, Tony Luck <tony.luck@intel.com>,
Dave Martin <Dave.Martin@arm.com>,
Babu Moger <babu.moger@amd.com>,
Drew Fustini <fustini@kernel.org>,
"chen.yu@linux.dev" <chen.yu@linux.dev>
Subject: Re: [RFC] mpam,x86,fs/resctrl: Generic schema description Proof of Concept
Date: Sat, 18 Jul 2026 00:02:41 +0800 [thread overview]
Message-ID: <4b297b46-995b-4b94-9fb0-bd69276dc957@intel.com> (raw)
In-Reply-To: <44f26cd4-be79-476e-b002-7ccfb7705179@intel.com>
Hi Reinette,
On 7/17/2026 12:04 AM, Reinette Chatre wrote:
> Hi Ben, Chenyu, and Tony,
>
[ ... ]
>>>> 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.
Would this approach also work for region‑aware MBA, where a "mode" file
is used to
toggle between "MB" and "MB_REGIONx_MAX", ensuring that the two are
never displayed
simultaneously in the schemata?
[ ... ]
> RDT region aware when using MSR interface for legacy controls
> =============================================================
Do you mean there is a requirement to use the MSR interface when
region‑aware
MMIO is available? My thought was that, if fine‑grained control(like
MMIO) is
available, it would be good to always let the fine‑grained control
emulate the
legacy one.
And I'm trying to figure out the definition of "legacy controls":
Previously I thought that "legacy control" means using the existing MB
interface
in the schemata to change the percentage value. That is to say, no
matter whether
the underlying mechanism is based on MSR or MMIO, it is transparent to the
resctrl user.
For example, if the mode is "legacy", and user writes "MB:0=50" to the
schemata
file,
1. If that platform only supports the MSR interface, then it will be
translated
into an MSR write. Or,
2. If that platform supports MMIO access (i.e., the ACPI table is
available),
we convert 50 into 50 × 255 / 100, and write it to the MMIO address. In
this way,
the user still sees the "legacy" interface.
> 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:...
>
>
If I understand correctly, the "enable/disable" knobs are used to decide
whether to display this control in the schemata file. If we make legacy
and native exclusive, do we still need the "enable/disable" knob?
On a platform where MSR/MMIO are both available:
1) System default
info hierarchy
--------------
info/
└── MB/
└── schemata/
├── MB/
│ ├── MB_REGION0_MAX/
│ ├── MB_REGION1_MAX/
│ ├── MB_REGION2_MAX/
│ ├── MB_REGION3_MAX/
└── 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/
│ ├── MB_REGION1_MAX/
│ ├── MB_REGION2_MAX/
│ ├── MB_REGION3_MAX/
└── mode:legacy [native]
schemata file
-------------
MB_REGION0_MAX:...
MB_REGION1_MAX:...
MB_REGION2_MAX:...
MB_REGION3_MAX:...
next prev parent reply other threads:[~2026-07-17 16:03 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
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 [this message]
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=4b297b46-995b-4b94-9fb0-bd69276dc957@intel.com \
--to=yu.c.chen@intel.com \
--cc=Dave.Martin@arm.com \
--cc=babu.moger@amd.com \
--cc=ben.horgan@arm.com \
--cc=bp@alien8.de \
--cc=chen.yu@linux.dev \
--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=reinette.chatre@intel.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
/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
Powered by JetHome