mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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>, Will Deacon <will@kernel.org>,
	Dave Martin <Dave.Martin@arm.com>,
	Catalin Marinas <catalin.marinas@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>,
	Richard Cheng <icheng@nvidia.com>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Fenghua Yu <fenghuay@nvidia.com>
Subject: [PATCH RFC v1 6/6] Documentation: resctrl: document MB_MAXHLM for MPAM MBA
Date: Mon,  9 Nov 2026 13:29:37 -0800	[thread overview]
Message-ID: <20261109212937.1409570-7-fenghuay@nvidia.com> (raw)
In-Reply-To: <20261109212937.1409570-1-fenghuay@nvidia.com>

The hard-limit interface is the MB_MAXHLM or MB_MAXHLM_NODE schemata
line. HARDLIM is read/write only when MPAMF_MBW_IDR.MAX_LIM is zero.
Existing resctrl documentation covers percentage MBA only.

Document both schemata lines (0/1 per domain) and how they relate to
MPAM MBW_MAX, HARDLIM, and MPAMF_MBW_IDR.MAX_LIM.

Signed-off-by: Fenghua Yu <fenghuay@nvidia.com>
---
 Documentation/filesystems/resctrl.rst | 28 +++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst
index b7ffedc02b41..2335fb91e5c6 100644
--- a/Documentation/filesystems/resctrl.rst
+++ b/Documentation/filesystems/resctrl.rst
@@ -1198,6 +1198,34 @@ When MB domains are NUMA nodes::
 
 	MB_NODE:<node_id0>=bw_MiBps0;<node_id1>=bw_MiBps1;...
 
+MBW maximum hard limit (ARM MPAM)
+---------------------------------
+On some ARM systems, resctrl memory bandwidth allocation uses MPAM
+maximum bandwidth (MBW_MAX). When ``MPAMF_MBW_IDR.MAX_LIM`` is 0, an
+additional schemata line selects the ``HARDLIM`` bit for
+``MPAMCFG_MBW_MAX`` independently of the numeric limit on the bandwidth
+line (``MB`` or ``MB_NODE``).
+
+The line uses the same domain indices as the bandwidth line. On a
+cache MSC those indices are cache ids and the lines are ``MB`` and
+``MB_MAXHLM``. On a memory-level MSC those indices are NUMA node ids
+and the lines are ``MB_NODE`` and ``MB_MAXHLM_NODE``. Each hard-limit
+value must be ``0`` or ``1``: ``0`` clears HARDLIM (soft-limit behaviour
+for the max), ``1`` sets HARDLIM (hard limit). When ``MAX_LIM`` is
+nonzero or the platform does not support the hard-limit control, the
+line is omitted from ``schemata``.
+
+The control is listed under ``info/MB/schemata/`` as ``MB_MAXHLM`` or
+``MB_MAXHLM_NODE``.
+
+Format when MB domains are caches::
+
+	MB_MAXHLM:<cache_id0>=0|1;<cache_id1>=0|1;...
+
+Format when MB domains are NUMA nodes::
+
+	MB_MAXHLM_NODE:<node_id0>=0|1;<node_id1>=0|1;...
+
 Slow Memory Bandwidth Allocation (SMBA)
 ---------------------------------------
 AMD hardware supports Slow Memory Bandwidth Allocation (SMBA).
-- 
2.53.0


      parent reply	other threads:[~2026-11-09 21:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-09 21:29 [PATCH RFC v1 0/6] arm_mpam,resctrl: expose MPAM MBW_MAX hard limit Fenghua Yu
2026-11-09 21:29 ` [PATCH RFC v1 1/6] resctrl: wire MB_MAXHLM schemata parsing and group setup Fenghua Yu
2026-11-09 21:29 ` [PATCH RFC v1 2/6] arm_mpam: resctrl: probe MPAMF_MBW_IDR MAX_LIM and hardlim_rw Fenghua Yu
2026-11-09 21:29 ` [PATCH RFC v1 3/6] arm_mpam: resctrl: track MBW max hard-limit in config Fenghua Yu
2026-11-09 21:29 ` [PATCH RFC v1 4/6] arm_mpam: resctrl: add MAXHLM control on the MBA resource Fenghua Yu
2026-11-09 21:29 ` [PATCH RFC v1 5/6] arm_mpam: Add MB_MAXHLM_NODE and Node scope Fenghua Yu
2026-11-09 21:29 ` Fenghua Yu [this message]

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=20261109212937.1409570-7-fenghuay@nvidia.com \
    --to=fenghuay@nvidia.com \
    --cc=Dave.Martin@arm.com \
    --cc=babu.moger@amd.com \
    --cc=ben.horgan@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=fustini@kernel.org \
    --cc=icheng@nvidia.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=will@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

all inboxes | Powered by JetHome®