From: Ben Horgan <ben.horgan@arm.com>
To: ben.horgan@arm.com, will@kernel.org
Cc: james.morse@arm.com, fenghuay@nvidia.com,
linux-arm-kernel@lists.infradead.org, andre.przywara@arm.com,
gshan@redhat.com, tan.shaopeng@jp.fujitsu.com,
sdonthineni@nvidia.com, jonathan.cameron@oss.qualcomm.com
Subject: [PATCH 5/6] arm64: mpam: Add memory bandwidth usage (MBWU) documentation
Date: Fri, 31 Jul 2026 18:52:42 +0100 [thread overview]
Message-ID: <20260731175243.904730-6-ben.horgan@arm.com> (raw)
In-Reply-To: <20260731175243.904730-1-ben.horgan@arm.com>
Memory bandwidth monitoring make uses of MBWU monitors and is now exposed
to the user via resctrl. Add some documentation so the user knows what to
expect.
Co-developed-by: James Morse <james.morse@arm.com>
Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Ben Horgan <ben.horgan@arm.com>
Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
Reviewed-by: Fenghua Yu <fenghuay@nvidia.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
---
Changes since v4:
Add paragraph about the future.
Changes since v5:
Add R-b's from Fenghua and Gavin
---
Documentation/arch/arm64/mpam.rst | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/Documentation/arch/arm64/mpam.rst b/Documentation/arch/arm64/mpam.rst
index 570f51a8d4eb..67fe515ed501 100644
--- a/Documentation/arch/arm64/mpam.rst
+++ b/Documentation/arch/arm64/mpam.rst
@@ -65,6 +65,28 @@ The supported features are:
there is at least one CSU monitor on each MSC that makes up the L3 group.
Exposing CSU counters from other caches or devices is not supported.
+* Memory Bandwidth Usage (MBWU) on or after the L3 cache. resctrl uses the
+ L3 cache-id to identify where the memory bandwidth is measured. For this
+ reason the platform must have an L3 cache with cache-id's supplied by
+ firmware. (The platform doesn't need to support MPAM.)
+
+ Memory bandwidth monitoring makes use of MBWU monitors in each MSC that
+ makes up the L3 group. If the memory bandwidth monitoring is on the memory
+ rather than the L3 then there must be a single global L3 as otherwise it
+ is unknown which L3 the traffic came from.
+
+ To expose 'mbm_total_bytes', the topology of the group of MSC chosen must
+ match the topology of the L3 cache so that the cache-id's can be
+ repainted. For example: Platforms with Memory bandwidth monitors on
+ CPU-less NUMA nodes cannot expose 'mbm_total_bytes' as these nodes do not
+ have a corresponding L3 cache. 'mbm_local_bytes' is not exposed as MPAM
+ cannot distinguish local traffic from global traffic.
+
+ All these restrictions based on L3 cache are due to resctrl, currently, only
+ supporting monitoring at the L3 scope. It is expected that going forward more
+ MBWU monitors can be exposed to the user after support for more monitoring
+ scopes is added to resctrl.
+
Reporting Bugs
==============
If you are not seeing the counters or controls you expect please share the
--
2.43.0
next prev parent reply other threads:[~2026-07-31 17:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-31 17:52 MPAM changes for v7.3 Ben Horgan
2026-07-31 17:52 ` [PATCH 1/6] arm_mpam: resctrl: Pick classes for use as MBM counters Ben Horgan
2026-07-31 17:52 ` [PATCH 2/6] arm_mpam: resctrl: Pre-allocate assignable monitors Ben Horgan
2026-07-31 17:52 ` [PATCH 3/6] arm_mpam: resctrl: Add resctrl_arch_config_cntr() for ABMC use Ben Horgan
2026-07-31 17:52 ` [PATCH 4/6] arm_mpam: resctrl: Add resctrl_arch_cntr_read() & resctrl_arch_reset_cntr() Ben Horgan
2026-07-31 17:52 ` Ben Horgan [this message]
2026-07-31 17:52 ` [PATCH 6/6] arm_mpam: Apply T241-MPAM-6 to 63-bit counters Ben Horgan
2026-08-01 0:23 ` 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=20260731175243.904730-6-ben.horgan@arm.com \
--to=ben.horgan@arm.com \
--cc=andre.przywara@arm.com \
--cc=fenghuay@nvidia.com \
--cc=gshan@redhat.com \
--cc=james.morse@arm.com \
--cc=jonathan.cameron@oss.qualcomm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=sdonthineni@nvidia.com \
--cc=tan.shaopeng@jp.fujitsu.com \
--cc=will@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