Linux Documentation
 help / color / mirror / Atom feed
From: Ben Horgan <ben.horgan@arm.com>
To: Jinjie Ruan <ruanjinjie@huawei.com>,
	reinette.chatre@intel.com, james.morse@arm.com,
	fenghuay@nvidia.com, catalin.marinas@arm.com, will@kernel.org,
	mark.rutland@arm.com, corbet@lwn.net, skhan@linuxfoundation.org,
	rdunlap@infradead.org, tony.luck@intel.com, Dave.Martin@arm.com,
	babu.moger@amd.com, tglx@kernel.org, mingo@redhat.com,
	bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com,
	tan.shaopeng@jp.fujitsu.com, jic23@kernel.org,
	zengheng4@huawei.com, gshan@redhat.com, x86@kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org
Subject: Re: [RFC PATCH v2 01/19] arm_mpam: resctrl: Leave CDP off when there are too few PARTIDs
Date: Fri, 30 Oct 2026 16:38:03 +0000	[thread overview]
Message-ID: <bea9392d-a9d1-4683-ba2c-41139a1dca9d@arm.com> (raw)
In-Reply-To: <20261029123611.1108424-2-ruanjinjie@huawei.com>

Hi Jinjie,

Thanks for this fix!

On 29/10/2026 12:35, Jinjie Ruan wrote:
> Enabling CDP needs a second PARTID for the reserved closid.

I'm not sure what a 'reserved closid' is here but you could just say:

Enabling CDP requires at least 2 PARTIDs.

> If firmware
> reports too few PARTIDs, resctrl_arch_set_cdp_enabled() returns -EINVAL,

Not all systems are firmware backed. This can be:

If there are too few PARTIDs, ... .

> but only after it has recorded CDP as enabled, halved the monitor count
> and turned off the mbw_max MBA control. 


> resctrl then reports an error
> and believes CDP is off, which leaves the two sides out of step and the
> halved monitor count and the missing MBA control are not undone.

I think the 'reports an error part' can be dropped leaving 'resctrl then believes CDP is off...' as
exactly what resctrl does is not important here.

> 
> Check the PARTID limit, and work out the CDP PARTIDs, before anything is

Why work out the CDP PARTIDs so early if they aren't going to be used?

> changed so a failed enable has no effect.
> 
> Fixes: 6789fb99282c ("arm_mpam: resctrl: Add CDP emulation")
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
>  drivers/resctrl/mpam_resctrl.c | 20 ++++++++++++--------
>  1 file changed, 12 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c
> index 5468367776e2..886f0595d364 100644
> --- a/drivers/resctrl/mpam_resctrl.c
> +++ b/drivers/resctrl/mpam_resctrl.c
> @@ -210,6 +210,18 @@ int resctrl_arch_set_cdp_enabled(enum resctrl_res_level rid, bool enable)
>  	if (enable)
>  		pr_warn("CDP is an expert feature and may cause MPAM to malfunction.\n");
>  
> +	/*
> +	 * Check this before changing any state: if CDP can't be enabled the
> +	 * caller must see CDP left off.
> +	 */

I don't think this comment is needed. Failing early rather than failing late after some side effects
have happened is clearly better.

> +	if (enable) {
> +		if (mpam_partid_max < 1)
> +			return -EINVAL;
> +
> +		partid_d = resctrl_get_config_index(RESCTRL_RESERVED_CLOSID, CDP_DATA);
> +		partid_i = resctrl_get_config_index(RESCTRL_RESERVED_CLOSID, CDP_CODE);

The partid_d/partid_i determination can stay below so it's close to the user.

I think we can just have the check here:

if (enable && mpam_partid_max < 1)
  	return -EINVAL;

Thanks,

Ben

> +	}
> +
>  	/*
>  	 * resctrl_arch_set_cdp_enabled() is only called with enable set to
>  	 * false on error and unmount.
> @@ -238,14 +250,6 @@ int resctrl_arch_set_cdp_enabled(enum resctrl_res_level rid, bool enable)
>  	if (!cdp_enabled && mpam_resctrl_controls[RDT_RESOURCE_MBA].class)
>  		mpam_resctrl_controls[RDT_RESOURCE_MBA].resctrl_res.alloc_capable = true;
>  
> -	if (enable) {
> -		if (mpam_partid_max < 1)
> -			return -EINVAL;
> -
> -		partid_d = resctrl_get_config_index(RESCTRL_RESERVED_CLOSID, CDP_DATA);
> -		partid_i = resctrl_get_config_index(RESCTRL_RESERVED_CLOSID, CDP_CODE);
> -	}
> -
>  	mpam_set_task_partid_pmg(current, partid_d, partid_i, 0, 0);
>  	WRITE_ONCE(arm64_mpam_global_default, mpam_get_regval(current));
>  


  reply	other threads:[~2026-10-30 16:38 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-29 12:35 [RFC PATCH v2 00/19] resctrl: Generalize monitor events across resources Jinjie Ruan
2026-10-29 12:35 ` [RFC PATCH v2 01/19] arm_mpam: resctrl: Leave CDP off when there are too few PARTIDs Jinjie Ruan
2026-10-30 16:38   ` Ben Horgan [this message]
2026-10-29 12:35 ` [RFC PATCH v2 02/19] fs/resctrl: Generalize __l3_mon_event_count for non-L3 resources Jinjie Ruan
2026-10-29 12:35 ` [RFC PATCH v2 03/19] fs/resctrl: Rename monitor events to drop the L3 prefix Jinjie Ruan
2026-10-29 12:35 ` [RFC PATCH v2 04/19] x86/resctrl: Use the resource-agnostic monitor event names Jinjie Ruan
2026-10-29 12:35 ` [RFC PATCH v2 05/19] arm_mpam: resctrl: " Jinjie Ruan
2026-10-29 12:35 ` [RFC PATCH v2 06/19] resctrl: Remove the L3 " Jinjie Ruan
2026-10-29 12:35 ` [RFC PATCH v2 07/19] arm_mpam: resctrl: Index monitor state by resource and event Jinjie Ruan
2026-10-29 12:36 ` [RFC PATCH v2 08/19] arm_mpam: resctrl: Halve the monitor counts of every resource on CDP Jinjie Ruan
2026-10-29 12:36 ` [RFC PATCH v2 09/19] x86,fs/resctrl: Pass the resource to the monitor event helpers Jinjie Ruan
2026-10-29 12:36 ` [RFC PATCH v2 10/19] fs/resctrl: Track monitor events per resource Jinjie Ruan
2026-10-29 12:36 ` [RFC PATCH v2 11/19] fs/resctrl: Add the L2 monitor events Jinjie Ruan
2026-10-29 12:36 ` [RFC PATCH v2 12/19] fs/resctrl: Set up MBM state and workers for every monitor resource Jinjie Ruan
2026-10-29 12:36 ` [RFC PATCH v2 13/19] fs/resctrl: Check RMID limbo on every resource with occupancy Jinjie Ruan
2026-10-29 12:36 ` [RFC PATCH v2 14/19] fs/resctrl: Manage assignable counters for every monitor resource Jinjie Ruan
2026-10-29 12:36 ` [RFC PATCH v2 15/19] arm_mpam: resctrl: Look up the monitor domain id from the components Jinjie Ruan
2026-10-29 12:36 ` [RFC PATCH v2 16/19] arm_mpam: resctrl: Report counter assignment per resource Jinjie Ruan
2026-10-29 12:36 ` [RFC PATCH v2 17/19] arm_mpam: resctrl: Allow monitoring on resources other than the L3 Jinjie Ruan
2026-10-29 12:36 ` [RFC PATCH v2 18/19] arm_mpam: resctrl: Expose the L2 monitor events Jinjie Ruan
2026-10-29 12:36 ` [RFC PATCH v2 19/19] Documentation: arm64: mpam: Describe " Jinjie Ruan
2026-10-30 17:09 ` [RFC PATCH v2 00/19] resctrl: Generalize monitor events across resources Reinette Chatre

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=bea9392d-a9d1-4683-ba2c-41139a1dca9d@arm.com \
    --to=ben.horgan@arm.com \
    --cc=Dave.Martin@arm.com \
    --cc=babu.moger@amd.com \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=fenghuay@nvidia.com \
    --cc=gshan@redhat.com \
    --cc=hpa@zytor.com \
    --cc=james.morse@arm.com \
    --cc=jic23@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=rdunlap@infradead.org \
    --cc=reinette.chatre@intel.com \
    --cc=ruanjinjie@huawei.com \
    --cc=skhan@linuxfoundation.org \
    --cc=tan.shaopeng@jp.fujitsu.com \
    --cc=tglx@kernel.org \
    --cc=tony.luck@intel.com \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    --cc=zengheng4@huawei.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