From: Jinjie Ruan <ruanjinjie@huawei.com>
To: Ben Horgan <ben.horgan@arm.com>, <catalin.marinas@arm.com>,
<will@kernel.org>, <mark.rutland@arm.com>, <corbet@lwn.net>,
<skhan@linuxfoundation.org>, <rdunlap@infradead.org>,
<james.morse@arm.com>, <reinette.chatre@intel.com>,
<fenghuay@nvidia.com>, <tony.luck@intel.com>,
<Dave.Martin@arm.com>, <babu.moger@amd.com>, <x86@kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-doc@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 0/7] arm_mpam: Add L2 cache monitors
Date: Wed, 28 Oct 2026 14:50:29 +0800 [thread overview]
Message-ID: <e0475b6d-3728-49e2-aab7-efd4c49593f1@huawei.com> (raw)
In-Reply-To: <c1e80268-3981-48bb-b251-dcd2218fc9d5@arm.com>
在 2026/10/26 19:46, Ben Horgan 写道:
> Hi Jinjie,
>
> On 22/10/2026 09:48, Jinjie Ruan wrote:
>> MPAM resource monitors hang off a partitionable resource in an MSC, not
>> off a particular cache level. resctrl only knows about the L3 scope, so
>> the L2 cache monitors that MPAM platforms implement are discovered by
>> the driver but never show up in resctrl.
>
> Yes, it would be good to add support for more monitoring scopes. This is not just relevant for MPAM.
> RISC-V can also have monitors at many places in the system and we should coordinate so we have a
> uniform solution across architectures.
Hi Ben,
Agree, we should take other emerging architectures such as RISC-V into
account, design a more extensible solution.
>
>>
>> An L2 MSC has the same CSU and MBWU counters as an L3 MSC; the cache
>> level comes from the ACPI MPAM table's cache locator. So this is mostly
>> a resctrl scope problem, not a hardware one.
>>
>> Extend resctrl's monitor scope to L2: register the L2 occupancy and
>> bandwidth events against the L2 resource, pick the L2 classes for them,
>> and borrow a CSU/MBWU monitor for the duration of a read. With CDP the
>
> Borrowing an MBWU monitor doesn't sound right. The MBWU monitor needs to be configured while the
> traffic is happening so that it can keep count of bytes. The CSU is different as it can measure the
> occupancy without having to keep any state.
Thank you very much, will drop this approach and try the compatible
solution you suggested.
>
> Thanks,
>
> Ben
>
>> two PARTIDs need separate accumulating monitors, so the borrowed-monitor
>> context becomes one monitor per PARTID.
>>
>> Patches:
>>
>> 1-2 Generalise the per-domain read path, add l2c_occupancy and
>> mbm_core_bytes, update the documentation.
>>
>> 3 Split the borrowed-monitor context into data and code entries.
>>
>> 4 Do the CDP num_rmid halving for every mon_capable resource.
>>
>> 5-7 Pick the L2 classes, describe the events with the L2 resource,
>> add the read paths.
>>
>> Tested on QEMU with an L2/L3/memory-controller MSC topology. The L2_MON
>> files show up and are readable; l2c_occupancy reports the modelled
>> occupancy, and mbm_core_bytes reports the modelled bandwidth.
>>
>> QEMU branch: https://github.com/ruanjinjie-eng/qemu/tree/mpam
>> Test cases: https://github.com/ruanjinjie-eng/mpam_testcase
>>
>> Jinjie Ruan (7):
>> fs/resctrl: Generalize __l3_mon_event_count for non-L3 resources
>> fs/resctrl: Add the L2 monitor events
>> arm_mpam: resctrl: Split monitor context for code/data
>> arm_mpam: resctrl: Halve num_rmid for every mon_capable resource on
>> CDP
>> arm_mpam: resctrl: Describe the L2 monitor events with the L2 resource
>> arm_mpam: resctrl: Pick L2 classes for the L2 monitor events
>> arm_mpam: resctrl: Add the L2 monitor read paths
>>
>> Documentation/arch/arm64/mpam.rst | 23 +--
>> drivers/resctrl/mpam_resctrl.c | 236 +++++++++++++++++++++++-------
>> fs/resctrl/monitor.c | 15 +-
>> include/linux/resctrl_types.h | 13 +-
>> 4 files changed, 222 insertions(+), 65 deletions(-)
>>
>
--
Best regards,
Jinjie
prev parent reply other threads:[~2026-10-28 6:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-22 8:48 [RFC PATCH 0/7] arm_mpam: Add L2 cache monitors Jinjie Ruan
2026-10-22 8:48 ` [RFC PATCH 1/7] fs/resctrl: Generalize __l3_mon_event_count for non-L3 resources Jinjie Ruan
2026-10-22 8:48 ` [RFC PATCH 2/7] fs/resctrl: Add the L2 monitor events Jinjie Ruan
2026-10-26 11:50 ` Ben Horgan
2026-10-28 6:44 ` Jinjie Ruan
2026-10-22 8:48 ` [RFC PATCH 3/7] arm_mpam: resctrl: Split monitor context for code/data Jinjie Ruan
2026-10-22 8:48 ` [RFC PATCH 4/7] arm_mpam: resctrl: Halve num_rmid for every mon_capable resource on CDP Jinjie Ruan
2026-10-22 8:48 ` [RFC PATCH 5/7] arm_mpam: resctrl: Describe the L2 monitor events with the L2 resource Jinjie Ruan
2026-10-22 8:48 ` [RFC PATCH 6/7] arm_mpam: resctrl: Pick L2 classes for the L2 monitor events Jinjie Ruan
2026-10-22 8:48 ` [RFC PATCH 7/7] arm_mpam: resctrl: Add the L2 monitor read paths Jinjie Ruan
2026-10-26 11:46 ` [RFC PATCH 0/7] arm_mpam: Add L2 cache monitors Ben Horgan
2026-10-28 6:50 ` Jinjie Ruan [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=e0475b6d-3728-49e2-aab7-efd4c49593f1@huawei.com \
--to=ruanjinjie@huawei.com \
--cc=Dave.Martin@arm.com \
--cc=babu.moger@amd.com \
--cc=ben.horgan@arm.com \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=fenghuay@nvidia.com \
--cc=james.morse@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=rdunlap@infradead.org \
--cc=reinette.chatre@intel.com \
--cc=skhan@linuxfoundation.org \
--cc=tony.luck@intel.com \
--cc=will@kernel.org \
--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