From: Reinette Chatre <reinette.chatre@intel.com>
To: Jinjie Ruan <ruanjinjie@huawei.com>, <james.morse@arm.com>,
<ben.horgan@arm.com>, <fenghuay@nvidia.com>,
<tony.luck@intel.com>, <Dave.Martin@arm.com>,
<babu.moger@amd.com>, <x86@kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 00/10] arm_mpam: Add extra MPAM controls in resctrl
Date: Fri, 23 Oct 2026 08:11:51 -0700 [thread overview]
Message-ID: <34dcdf73-5404-406a-99a5-60630032c054@intel.com> (raw)
In-Reply-To: <20261023024812.232820-1-ruanjinjie@huawei.com>
Hi Jinjie,
On 10/22/26 7:48 PM, Jinjie Ruan wrote:
> Hi all,
>
> Resctrl today only exposes CBM and the MBA bandwidth percentage.
> But MPAM MSCs also have per-PARTID fields for internal priority, capacity
> limits, a bandwidth minimum and the MBW_MAX hard-limit bit. The driver
> already writes these fields, but resctrl has no schemata line for them,
> so userspace can't choose the values.
>
> So this series adds those schemata lines:
>
> - Patch 1 fixes maybe_update_config(): a feature set with value zero
> counts as no change, so the register is not written again.
> The controls below can be zero, so this comes first.
>
> - Patches 2-4 add mbw_min/max_limit, cmax/cmin and intpri to
> mpam_config and write them from mpam_reprogram_ris_partid().
>
> - Patch 5 adds the resource levels, selects the range path by schema_fmt
> instead of the MBA/SMBA rid, skips the new resources in info/, and sets
> their default value when a group is created.
>
> - Patches 6-7 adjust the fixed-point helpers and clamp cmax_wd.
>
> - Patches 8-10 add the schemata lines:
>
> L2MAX/L3MAX CMAX, percent
> L2MIN/L3MIN CMIN, percent
> MBMIN MBW_MIN, percent
> L2PRI/L3PRI/MBPRI INTPRI, raw value
> MBHDL HARDLIM, 0 or 1
> MBOPT MBW_MAX, raw fraction
>
> The new resources reuse the class, domains and components of L2/L3/MB; only
> the mpam_config field written differs. MBOPT and MBA both write MBW_MAX.
>
> So before this series userspace can only set CBM and the MBA percentage.
> After it, you can do:
>
> # echo "L3MAX:33751040=50" > schemata
> # echo "MBHDL:33751040=1" > schemata
>
> A new group starts from each resource's default value, so the new controls
> stay out of the way until schemata is written.
>
> Tested this with a QEMU that has one L2 MSC, one L3 MSC and one
> memory-controller MSC (CMAX_WD 4, INTPRI_WD 2, BWA_WD 16). The guest writes
> every new line and reads it back, for example:
>
> WRITE-OK [L3MAX:33751040=50]
> SCHEMATA: L3MAX:33751040=50
>
> Then reads the MSC registers:
>
> L3 MSC partid0: PRI(IN)=2 CMIN=0x3000 CMAX=0x7000
> mem MSC partid0: PRI(IN)=1 MBW_MIN=0x3fff MBW_MAX=0x1fff HARDLIM=Y
>
> CMIN/CMAX are 4-bit fractions (3/16 for 25%, 7/16 for 50%); MBW_MIN is a
> 16-bit fraction (0x3fff for 25%); MBOPT writes the raw fraction (8191).
How does user space know what the valid control values are? What if a new
platform comes along with the same control but different properties of the
control value?
Please consider the ongoing work around adding support for multiple controls
to resctrl. Most recent RFC can be found at
https://lore.kernel.org/lkml/d258a32f-12d5-464d-abe9-4720fb3e44b3@intel.com/
An update on this can be found in LPC slides:
https://lpc.events/event/20/contributions/2368/attachments/2066/4625/resctrl_2026_combined.pdf
The work aims to make the distinction between a resource and its control clear.
It will expose the controls in the schemata file but also support it
with a hierarchy in the info/ directory that makes clear to user space how the
control is associated with the resource while also providing an interface from which
user space can learn what the valid control values are as well as what a domain value
represents.
Reinette
prev parent reply other threads:[~2026-10-23 15:11 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-23 2:48 Jinjie Ruan
2026-10-23 2:48 ` [RFC PATCH 01/10] arm_mpam: Treat adopting a config feature as a change Jinjie Ruan
2026-10-23 2:48 ` [RFC PATCH 02/10] arm_mpam: Carry mbw_min and the hard limit in mpam_config Jinjie Ruan
2026-10-23 2:48 ` [RFC PATCH 03/10] arm_mpam: Carry cmax and cmin " Jinjie Ruan
2026-10-23 2:48 ` [RFC PATCH 04/10] arm_mpam: Carry intpri " Jinjie Ruan
2026-10-23 2:48 ` [RFC PATCH 05/10] fs/resctrl: Prepare for range-format pseudo resources Jinjie Ruan
2026-10-23 2:48 ` [RFC PATCH 06/10] arm_mpam: Clamp cmax_wd to 16 Jinjie Ruan
2026-10-23 2:48 ` [RFC PATCH 07/10] arm_mpam: Generalize the fixed-point conversion helpers Jinjie Ruan
2026-10-23 2:48 ` [RFC PATCH 08/10] arm_mpam: resctrl: Expose the capacity controls as pseudo resources Jinjie Ruan
2026-10-23 2:48 ` [RFC PATCH 09/10] arm_mpam: resctrl: Expose the priority " Jinjie Ruan
2026-10-23 2:48 ` [RFC PATCH 10/10] arm_mpam: resctrl: Expose the bandwidth minimum and limit " Jinjie Ruan
2026-10-23 15:11 ` Reinette Chatre [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=34dcdf73-5404-406a-99a5-60630032c054@intel.com \
--to=reinette.chatre@intel.com \
--cc=Dave.Martin@arm.com \
--cc=babu.moger@amd.com \
--cc=ben.horgan@arm.com \
--cc=fenghuay@nvidia.com \
--cc=james.morse@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ruanjinjie@huawei.com \
--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
all inboxes | Powered by JetHome®