From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A7D8F2DF15C for ; Thu, 14 May 2026 17:06:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778778415; cv=none; b=Am1Monp1tqDJwSliE4ehtwPQ6pi0xaqRa0gDda6KQMj+mdOWNY6ji6/733HiFHpXOmRW/mfj81wLw5ZnOZz6sHphnuDX+ZR1pYiMsoDAzzIOE8f97H2Vef2hn+cPOxHjoF8T89xD3lVDc9IWyzSZ4FnKem9aSGO8kbLqNrPXSbA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778778415; c=relaxed/simple; bh=96W3qnxStGY+SaGABufKN0Q7dcunMPRX3gZeJLKjSro=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=CN18K0Veih/bQzKV2CWkw8Uil203K52z5ns8wnCq/2HIgIog8VH1gBFUl5Fcxmhs0hz7tVG5RLvIvraVe4aNt3FF6DxQvo7suFJhB2+BUzfB2yYDF5G5EH0aiLxzENdxVB5+dlqU+0PL5priGvarmqMV/5JXufSExfTlRIqCYds= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=qk0T+mjr; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="qk0T+mjr" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D4E933544; Thu, 14 May 2026 10:06:47 -0700 (PDT) Received: from [10.1.196.96] (eglon.cambridge.arm.com [10.1.196.96]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8E4D23F836; Thu, 14 May 2026 10:06:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1778778413; bh=96W3qnxStGY+SaGABufKN0Q7dcunMPRX3gZeJLKjSro=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=qk0T+mjrq7g7tiXwenYqR1tnu6+zSav2TXCRRDCQFp2ijNNbL5T0B2MAhb8+Gq30P iCEtM7HjGdURZ8QXf7ZXbckB3Ft/HWUblG3LDnoZmFfzZ+hXcV4YEpw0kpcOQpqgF5 7HhNDKoMFBCibwzkWW76ksek3z5anZwU6brjQhT8= Message-ID: <9efc30be-689b-4f42-bef0-d7d62b4392fa@arm.com> Date: Thu, 14 May 2026 18:06:47 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 next 03/10] arm_mpam: Disable reqPARTID expansion when Narrow-PARTID is unavailable To: Zeng Heng , ben.horgan@arm.com, Dave.Martin@arm.com, tan.shaopeng@jp.fujitsu.com, reinette.chatre@intel.com, fenghuay@nvidia.com, tglx@kernel.org, will@kernel.org, hpa@zytor.com, bp@alien8.de, babu.moger@amd.com, dave.hansen@linux.intel.com, mingo@redhat.com, tony.luck@intel.com, gshan@redhat.com, catalin.marinas@arm.com Cc: linux-arm-kernel@lists.infradead.org, x86@kernel.org, linux-kernel@vger.kernel.org, wangkefeng.wang@huawei.com References: <20260413085405.1166412-1-zengheng4@huawei.com> <20260413085405.1166412-4-zengheng4@huawei.com> Content-Language: en-GB From: James Morse In-Reply-To: <20260413085405.1166412-4-zengheng4@huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Zeng, On 13/04/2026 09:53, Zeng Heng wrote: > MPAM supports heterogeneous systems where some type of MSCs may implement > Narrow-PARTID while others do not. However, when an MSC uses > percentage-based throttling (non-bitmap partition control) and lacks > Narrow-PARTID support, resctrl cannot correctly apply control group > configurations across multiple PARTIDs. > > To enable free assignment of multiple reqPARTIDs to resource control > groups, all MSCs used by resctrl must either: Implement Narrow-PARTID, > allowing explicit PARTID remapping, or only have stateless resource > controls (non-percentage-based), such that splitting a control group > across multiple PARTIDs does not affect behavior. I prefer Dave's terminology for this: aliasing and non-aliasing. It implies there are two controls, which stateless does not. > The detection occurs at initialization time on the first call to > get_num_reqpartid() from update_rmid_limits(). This call is guaranteed > to occur after mpam_resctrl_pick_{mba,caches}() have set up the > resource classes, ensuring the necessary properties are available > for the Narrow-PARTID capability check. > > When an MSC with percentage-based control lacks Narrow-PARTID support, > get_num_reqpartid() falls back to returning the number of intPARTIDs, > effectively disabling the reqPARTID expansion for monitoring groups. No MSC has percentage based controls - that's an x86ism. The MSCs have fixed point fractions, bitmaps or a cost/weight. I think you're thinking about this the wrong way up - we should only enable this on a small number of platforms that don't have any controls we'd have to discard. (hopefully yours is such a platform!) I don't think this should be added to resctrl_arch_system_num_rmid_idx(). Please make this decision for resctrl at mpam_resctrl_setup() time. > diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c > index 5f4364c8101a..56859f354efa 100644 > --- a/drivers/resctrl/mpam_resctrl.c > +++ b/drivers/resctrl/mpam_resctrl.c > @@ -257,9 +257,50 @@ u32 resctrl_arch_get_num_closid(struct rdt_resource *ignored) > return mpam_intpartid_max + 1; > } > > +/* > + * Determine the effective number of PARTIDs available for resctrl. > + * > + * This function performs a one-time check to determine if Narrow-PARTID > + * can be used. It must be called after mpam_resctrl_pick_{mba,caches}() > + * have initialized the resource classes, as class properties are used > + * to detect Narrow-PARTID support. > + * The first call occurs in update_rmid_limits(), ensuring the > + * prerequisite initialization is complete. This is fragile to changes in the order resctrl makes these calls. We need these properties to be fixed before we call resctrl_init(). (yes - I think CDP is fragile too!) > + */ > +static u32 get_num_reqpartid(void) > +{ > + struct mpam_resctrl_res *res; > + struct mpam_props *cprops; > + static bool first = true; > + int rid; > + > + if (first) { > + for_each_mpam_resctrl_control(res, rid) { > + if (!res->class) > + continue; > + > + cprops = &res->class->props; > + if (mpam_has_feature(mpam_feat_partid_nrw, cprops)) > + continue; > + if (mpam_has_feature(mpam_feat_mbw_max, cprops) || > + mpam_has_feature(mpam_feat_mbw_min, cprops) || > + mpam_has_feature(mpam_feat_cmax_cmax, cprops) || > + mpam_has_feature(mpam_feat_cmax_cmin, cprops)) { Please make this a helper in mpam_internal.h with 'controls' and 'aliasing' in its name. (maybe has_aliasing_controls()). What about the priority for PRI and the proportional-stride? I don't think proportional-stride aliases properly: if I have groups with stride 1 and 2, I can't add a second '2' without decreasing the first groups stride from 1/3 to 1/5. If I halve the second groups, they each get half the bandwidth instead of sharing it. Can you check whether the priority for PRI aliases? > + mpam_partid_max = mpam_intpartid_max; > + break; > + } > + } > + } > + > + first = false; > + return mpam_partid_max + 1; > +} > + > u32 resctrl_arch_system_num_rmid_idx(void) > { > - return (mpam_pmg_max + 1) * (mpam_partid_max + 1); > + return (mpam_pmg_max + 1) * get_num_reqpartid(); > } Thanks, James