From: Fenghua Yu <fenghuay@nvidia.com>
To: Reinette Chatre <reinette.chatre@intel.com>,
Tony Luck <tony.luck@intel.com>, Ben Horgan <ben.horgan@arm.com>,
James Morse <james.morse@arm.com>,
Dave Martin <Dave.Martin@arm.com>,
Shaopeng Tan <tan.shaopeng@fujitsu.com>,
Chen Yu <yu.c.chen@intel.com>, Babu Moger <babu.moger@amd.com>,
Drew Fustini <fustini@kernel.org>,
Vikram Sethi <vsethi@nvidia.com>,
Shanker Donthineni <sdonthineni@nvidia.com>,
Newton Liu <newtonl@nvidia.com>, Gavin Shan <gshan@redhat.com>
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Fenghua Yu <fenghuay@nvidia.com>
Subject: [PATCH 08/23] Documentation: resctrl: document MBA control emulation
Date: Thu, 16 Jul 2026 14:02:58 -0700 [thread overview]
Message-ID: <20260716210329.2914625-8-fenghuay@nvidia.com> (raw)
In-Reply-To: <cover.1784217438.git.fenghuay@nvidia.com>
Describe the generic resctrl mechanism that lets a native control emulate
the legacy MB control so the MB: schemata line keeps working for existing
tools when the default MB control has no hardware of its own.
Document the info/<resource>/resource_schemata directory, its per-control
status file, and the writable legacy/native mode file, independent of any
particular architecture. Architecture-specific examples are added
separately.
Signed-off-by: Fenghua Yu <fenghuay@nvidia.com>
---
Documentation/filesystems/resctrl.rst | 93 +++++++++++++++++++++++++++
1 file changed, 93 insertions(+)
diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst
index e4b66af55ffb..0de86d00c0a6 100644
--- a/Documentation/filesystems/resctrl.rst
+++ b/Documentation/filesystems/resctrl.rst
@@ -81,6 +81,28 @@ to modify those settings.
Each subdirectory contains the following files with respect to
allocation:
+"resource_schemata":
+ Directory describing the controls exposed for each alloc-capable
+ resource (for example L3, L2, and MB). Each control has its own
+ subdirectory. Control names are formed from the resource name and
+ an optional suffix when a resource exposes more than one control
+ (for example ``MB`` and ``MB_NODE`` on MBA resources).
+
+ Each control subdirectory is read-only and contains ``scope``
+ and ``type`` files. Bandwidth (scalar) controls also expose a
+ ``status`` file that reads ``enabled`` when the control is backed
+ by bandwidth-control hardware and ``disabled`` otherwise.
+
+ On resources that support control emulation (see "MBA control
+ emulation" below), this directory also contains a writable
+ ``mode`` file that selects the active control mode (``legacy``
+ or ``native``). This is not the same as the per-resource-group
+ ``mode`` file described below under "Resource Groups", which
+ selects shareable/exclusive cache allocation. Switching emulation
+ modes only changes observable behaviour when the default control
+ is disabled and emulated by another control. On resources that do
+ not support control emulation, no ``mode`` file is created.
+
Cache resource(L3/L2) subdirectory contains the following files
related to allocation:
@@ -617,6 +639,10 @@ When control is enabled all CTRL_MON groups will also contain:
file. On successful pseudo-locked region creation the mode will
automatically change to "pseudo-locked".
+ This is not the ``mode`` file under ``info/<resource>/resource_schemata/``,
+ which selects MBA control emulation mode (``legacy`` or ``native``); see
+ "MBA control emulation" below.
+
"ctrl_hw_id":
Available only with debug option. The identifier used by hardware
for the control group. On x86 this is the CLOSID.
@@ -966,6 +992,73 @@ Memory b/w domain is L3 cache.
MB:<cache_id0>=bandwidth0;<cache_id1>=bandwidth1;...
+MBA control emulation
+---------------------
+Some platforms expose memory bandwidth allocation through a native control
+(for example a node-scoped control) rather than the legacy ``MB`` control
+that existing tools expect. To preserve backward compatibility, legacy mode
+(the default) keeps the ``MB:`` entry in ``schemata`` when the default
+``MB`` control has no hardware of its own. A native control emulates ``MB``
+behind the scenes so user tools that read or write only the ``MB:`` line
+continue to work. In native mode the disabled ``MB`` control has no
+``schemata`` line; tools use the native control's line instead.
+
+Nesting under ``resource_schemata`` and schemata mirroring take effect
+only when an architecture driver configures which control emulates which
+(for example by setting the ``emulated_by`` relationship described in the
+kernel API).
+
+When the default ``MB`` control has no MBW hardware of its own
+(``status`` reads ``disabled``), it is emulated by a native control in
+legacy mode. In that case:
+
+- The native control is nested under ``MB`` in
+ ``info/MB/resource_schemata/``.
+- Schemata reads and writes for the ``MB:`` line are mirrored through
+ the native control so both lines show and update the same values.
+
+When ``MB`` is enabled, the native control is a sibling of ``MB`` in
+``info/MB/resource_schemata/``, and the two controls operate
+independently.
+
+Emulation mode
+~~~~~~~~~~~~~~
+Whether a disabled control is emulated is selected by the writable
+``mode`` file in ``info/MB/resource_schemata/``. This is not the same
+as the per-resource-group ``mode`` file under each ``<group>/`` directory,
+which selects shareable/exclusive cache allocation; see "Resource Groups"
+above. Reading it shows the available modes with the active one in brackets,
+for example::
+
+ # cat /sys/fs/resctrl/info/MB/resource_schemata/mode
+ [legacy] native
+
+``legacy`` (default):
+ A disabled ``MB`` control is emulated by a native control. The
+ native control is nested under ``MB`` in
+ ``info/MB/resource_schemata/`` and schemata reads and writes for
+ the ``MB:`` line are mirrored through it. This keeps the ``MB:``
+ entry working for existing tools.
+
+``native``:
+ No emulation is performed. A disabled ``MB`` control has no ``MB:``
+ schemata line, the native control is a sibling of ``MB`` directly
+ under ``info/MB/resource_schemata/``, and each visible schemata line
+ only reflects its own hardware.
+
+The mode is changed by writing to the file::
+
+ # echo native > /sys/fs/resctrl/info/MB/resource_schemata/mode
+
+Switching mode rebuilds the ``info/MB/resource_schemata/`` control
+subdirectories so their nesting matches the new mode.
+
+While a mode write is being processed the control subdirectories are torn
+down and recreated, so a concurrent reader may briefly observe
+``resource_schemata/`` containing only the ``mode`` file. This is expected:
+the control subdirectories are informational only and the actual bandwidth
+configuration in each group's ``schemata`` file is unaffected.
+
Memory bandwidth Allocation specified in MiBps
----------------------------------------------
--
2.43.0
next prev parent reply other threads:[~2026-07-16 21:04 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-16 21:02 [PATCH RFC 00/23] resctrl: MBA control emulation and ARM MPAM MB_NODE support Fenghua Yu
2026-07-16 21:02 ` [PATCH 01/23] resctrl: Fix ownership of resource_schemata control subdirectories Fenghua Yu
2026-07-16 21:02 ` [PATCH 02/23] arm_mpam: Fix NULL address access issue Fenghua Yu
2026-07-16 21:02 ` [PATCH 03/23] resctrl: Expose MBA resource_schemata mode sysfs Fenghua Yu
2026-07-16 21:02 ` [PATCH 04/23] resctrl: Expose per-control status in resource_schemata Fenghua Yu
2026-07-16 21:02 ` [PATCH 05/23] resctrl: Add nested resource_schemata support for emulated controls Fenghua Yu
2026-07-16 21:02 ` [PATCH 06/23] resctrl: Mirror schemata for controls without MBW hardware Fenghua Yu
2026-07-16 21:02 ` [PATCH 07/23] resctrl: Rebuild resource_schemata subdirs on MBA mode change Fenghua Yu
2026-07-16 21:02 ` Fenghua Yu [this message]
2026-07-16 21:02 ` [PATCH 09/23] resctrl: De-hardcode L3 monitor infrastructure Fenghua Yu
2026-07-16 21:03 ` [PATCH 10/23] resctrl: Expose MBA MBM counter assignment sysfs Fenghua Yu
2026-07-16 21:03 ` [PATCH 11/23] resctrl: name node-scoped monitor domains mon_NODE_<id> Fenghua Yu
2026-07-16 21:03 ` [PATCH 12/23] resctrl: Add node-scope MBM total event Fenghua Yu
2026-07-16 21:03 ` [PATCH 13/23] resctrl: Make MBM paths resource-aware Fenghua Yu
2026-07-16 21:03 ` [PATCH 14/23] arm_mpam: Support memory-level MSCs and ABMC per class Fenghua Yu
2026-07-16 21:03 ` [PATCH 15/23] arm_mpam: Refine L3 topology and class selection Fenghua Yu
2026-07-16 21:03 ` [PATCH 16/23] arm_mpam: Include all MSC components during domain setup Fenghua Yu
2026-07-16 21:03 ` [PATCH 17/23] arm_mpam: Handle CPU-less numa nodes Fenghua Yu
2026-07-16 21:03 ` [PATCH 18/23] arm_mpam: Emulate MB control with node-scoped MB_NODE control Fenghua Yu
2026-07-16 21:03 ` [PATCH 19/23] Documentation: arm64: mpam: document memory-level MB control and NUMA nodes Fenghua Yu
2026-07-16 21:03 ` [PATCH 20/23] Documentation: resctrl: document NODE-scoped MBA domains and mon_NODE monitoring Fenghua Yu
2026-07-16 21:03 ` [PATCH 21/23] Documentation: resctrl: document MB_NODE emulation example on ARM MPAM Fenghua Yu
2026-07-16 21:03 ` [PATCH 22/23] arm_mpam: Add KUnit test for CPU-less NUMA node affinity Fenghua Yu
2026-07-16 21:03 ` [PATCH 23/23] selftests/resctrl: Add MB emulation test for ARM MPAM Fenghua Yu
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=20260716210329.2914625-8-fenghuay@nvidia.com \
--to=fenghuay@nvidia.com \
--cc=Dave.Martin@arm.com \
--cc=babu.moger@amd.com \
--cc=ben.horgan@arm.com \
--cc=fustini@kernel.org \
--cc=gshan@redhat.com \
--cc=james.morse@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=newtonl@nvidia.com \
--cc=reinette.chatre@intel.com \
--cc=sdonthineni@nvidia.com \
--cc=tan.shaopeng@fujitsu.com \
--cc=tony.luck@intel.com \
--cc=vsethi@nvidia.com \
--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