From: Reinette Chatre <reinette.chatre@intel.com>
To: Ben Horgan <ben.horgan@arm.com>, <james.morse@arm.com>,
<Dave.Martin@arm.com>, <fenghuay@nvidia.com>
Cc: <tony.luck@intel.com>, <babu.moger@amd.com>,
<yu.c.chen@intel.com>, <linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <patches@lists.linux.dev>
Subject: Re: [RFC PATCH] arm_mpam: resctrl: Separate MPAM domains
Date: Mon, 14 Sep 2026 09:52:40 -0700 [thread overview]
Message-ID: <4a5276ca-238c-418b-872e-3dd495b50171@intel.com> (raw)
In-Reply-To: <3571430b-15b5-4451-97e4-455f9fd46f01@arm.com>
Hi Ben,
On 9/14/26 9:11 AM, Ben Horgan wrote:
> On 14/09/2026 16:16, Reinette Chatre wrote:
>> On 9/11/26 1:56 AM, Ben Horgan wrote:
>>> On 10/09/2026 19:10, Reinette Chatre wrote:
>>
>>>>
>>>> Do (admittedly crude) guardrails like below capture the existing driver requirements?
>>>>
>>>> diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c
>>>> index 9d223057953a..dbd06371890c 100644
>>>> --- a/drivers/resctrl/mpam_resctrl.c
>>>> +++ b/drivers/resctrl/mpam_resctrl.c
>>>> @@ -1681,11 +1681,18 @@ mpam_resctrl_alloc_domain(unsigned int cpu, struct mpam_resctrl_res *res)
>>>> continue; // dummy resource
>>>>
>>>> mon_comp = find_component(mon->class, cpu);
>>>> + if (!mon_comp) {
>>>> + WARN_ON_ONCE(0);
>>>> + err = -EFAULT;
>>>> + goto offline_ctrl_domain;
>>>> + }
>>>> dom->mon_comp[eventid] = mon_comp;
>>>> - if (mon_comp)
>>>> - any_mon_comp = mon_comp;
>>>> + any_mon_comp = mon_comp;
>>>
>>> This first part which ensures that if there is a class for the monitor then a component can always
>>> be found for the given CPU.
>>>
>>>> }
>>>> - if (!any_mon_comp) {
>>>
>>> The any_mon_comp check could still be useful to confirm that if r->mon_capable then there is a
>>> component for at least one of the events.
>>
>> resctrl fs does not handle such scenario. r->mon_capable guides whether the resource
>> supports monitoring and if it is then all domains belonging to the resource is expected to
>> support all monitoring events associated with the resource. resctrl fs will expose all the
>> monitoring event files based on r->mon_capable and which monitoring events are enabled, there
>> is no finer grained support to expose/hide events per domain.
>
> Yes. I wasn't intending to suggest anything different. If r->mon_capable then the MPAM driver does
> support all enabled events. Maybe I would would have been more to correct to just say if
> r->mon_capable is true we confirm that we can do some monitoring.
ah - I see. Thank you for clarifying.
>> If any_mon_comp is true while one of the mon_comp is NULL then resctrl will still expose the
>> event to user space and pass attempts to read the data to MPAM driver.
>>
>> Is this a scenario that the MPAM driver needs to support? That is, users will see event files
>> but reading the data will succeed in some domains but fail in others?
>
> No, we don't expect the MPAM driver to support any features inconsistently across resctrl domains.
> If the hardware did happen to be mismatched then we sanitize it, in __class_props_mismatch() we
> ensure the class only exposes the features that are common to all the child components.
Thank you very much.
Reinette
prev parent reply other threads:[~2026-09-14 16:52 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-31 23:54 [RFC PATCH] arm_mpam: resctrl: Separate MPAM domains Reinette Chatre
2026-09-02 16:10 ` Ben Horgan
2026-09-03 15:29 ` Reinette Chatre
2026-09-07 17:01 ` Ben Horgan
2026-09-08 21:12 ` Reinette Chatre
2026-09-10 11:11 ` Ben Horgan
2026-09-10 15:37 ` Reinette Chatre
2026-09-10 16:28 ` Ben Horgan
2026-09-10 18:10 ` Reinette Chatre
2026-09-11 8:56 ` Ben Horgan
2026-09-14 15:16 ` Reinette Chatre
2026-09-14 16:11 ` Ben Horgan
2026-09-14 16:52 ` 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=4a5276ca-238c-418b-872e-3dd495b50171@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-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=patches@lists.linux.dev \
--cc=tony.luck@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.