From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout11.his.huawei.com (canpmsgout11.his.huawei.com [113.46.200.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C81F2249EB for ; Sat, 11 Apr 2026 06:50:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.226 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775890234; cv=none; b=Nzrp3E96IwBZcCDcI9qAVGWOWOO/39SQpu8D7mU37FfYDh5X9S0VVlK7UTXsJqhMWV5fFweoopIn2nQm4Zc/cAsuVgiznNDn2DS0MAjtOFeVry9ug+TXnLRyTwH4a5vt+YctS8wdWKuKv2Pqi+cZY1sFHl7d5lYrSCbU25JfAFE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775890234; c=relaxed/simple; bh=cncrk7W4S37N9ZZt7sNjSIyOdZMTmD/gSTCBJQ7/Omg=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=JTTIGtwC/Npk4f1gsqXxbhYYlinjOPCkQR5pmP8pPXBR0G9N4my5rizMnwogqZ45Rnkk7+32W40z068lHomeQBYF09yElYSdSHrNTgeyGpHsG9f7KGUE0PZ6PY9fMYqEQgS7IiaXE1m9gOOzeafbymr3iPGchp23/zhgDH+2bS4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=h-partners.com; dkim=pass (1024-bit key) header.d=h-partners.com header.i=@h-partners.com header.b=bAjrN716; arc=none smtp.client-ip=113.46.200.226 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=h-partners.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=h-partners.com header.i=@h-partners.com header.b="bAjrN716" dkim-signature: v=1; a=rsa-sha256; d=h-partners.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=QrfRBdZzl5NT1SC+uHND+QaN2TL+Rf62vF5Ow1Ulj9I=; b=bAjrN716FU6dHyMReq3gntusTRR+c4sgkdpeXDKpcB1C+Wwed84YblQ4buqiJFwa6+bKqcXMB nzfKHEzEz7PbUYBQ1kDPd9kNo7z/lfzwMrtTKaGaZv3i0wQz5ggsolJd+TV/x2O145q4MgseBnY gU1Jxz6Ks/kwEW9QDBtEHAM= Received: from mail.maildlp.com (unknown [172.19.163.127]) by canpmsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4ft3zk37GtzKm4k; Sat, 11 Apr 2026 14:44:02 +0800 (CST) Received: from kwepemf100008.china.huawei.com (unknown [7.202.181.222]) by mail.maildlp.com (Postfix) with ESMTPS id 20A54402AB; Sat, 11 Apr 2026 14:50:20 +0800 (CST) Received: from [10.174.179.37] (10.174.179.37) by kwepemf100008.china.huawei.com (7.202.181.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.36; Sat, 11 Apr 2026 14:50:18 +0800 Message-ID: <30d37733-db55-f29f-5bbf-1b69ed0846e5@huawei.com> Date: Sat, 11 Apr 2026 14:50:18 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH v3 3/9] arm_mpam: Disable Narrow-PARTID when MBA lacks support Content-Language: en-US To: "Shaopeng Tan (Fujitsu)" , "'ben.horgan@arm.com'" , "'james.morse@arm.com'" , "'Dave.Martin@arm.com'" , "'reinette.chatre@intel.com'" , "'fenghuay@nvidia.com'" CC: "'dave.hansen@linux.intel.com'" , "'tglx@kernel.org'" , "'mingo@redhat.com'" , "'hpa@zytor.com'" , "'bp@alien8.de'" , "'tony.luck@intel.com'" , "'babu.moger@amd.com'" , "'x86@kernel.org'" , "'linux-kernel@vger.kernel.org'" , "'wangkefeng.wang@huawei.com'" References: <20260317132141.1272506-4-zengheng4@huawei.com> From: Zeng Heng In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: kwepems200002.china.huawei.com (7.221.188.68) To kwepemf100008.china.huawei.com (7.202.181.222) On 2026/4/10 9:07, Shaopeng Tan (Fujitsu) wrote: > Hello Zeng Heng, > >> MPAM supports mixed systems with MSCs that may or may not implement >> Narrow-PARTID. However, when the MBA MSC uses percentage-based >> throttling (non-bitmap partition control) and lacks Narrow-PARTID support, >> resctrl cannot correctly apply control group configurations across multiple >> PARTIDs. >> >> Since there is no straightforward way to program compatible control values in >> this scenario, disable Narrow-PARTID system-wide when detected. The >> detection occurs at initialization time on the first call to get_num_reqpartid() >> from mpam_resctrl_pick_counters(), which is guaranteed to occur after >> mpam_resctrl_pick_mba() has set up the MBA resource class. >> >> If MBA MSCs lack Narrow-PARTID support, get_num_reqpartid() falls back to >> returning the number of internal PARTIDs (mpam_intpartid_max). >> >> Signed-off-by: Zeng Heng >> --- >> drivers/resctrl/mpam_resctrl.c | 38 >> +++++++++++++++++++++++++++++++++- >> 1 file changed, 37 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c >> index 222ea1d199e1..1b18c095cfce 100644 >> --- a/drivers/resctrl/mpam_resctrl.c >> +++ b/drivers/resctrl/mpam_resctrl.c >> @@ -240,9 +240,45 @@ 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() has >> + * initialized the MBA resource, as the MBA class properties are used >> + * to detect Narrow-PARTID support. >> + * >> + * The first call occurs in mpam_resctrl_pick_counters(), ensuring the >> + * prerequisite initialization is complete. >> + */ >> +static u32 get_num_reqpartid(void) >> +{ >> + struct mpam_resctrl_res *res; >> + struct rdt_resource *r_mba; >> + struct mpam_props *cprops; >> + static bool first = true; >> + >> + if (first) { >> + r_mba = resctrl_arch_get_resource(RDT_RESOURCE_MBA); >> + res = container_of(r_mba, struct mpam_resctrl_res, >> resctrl_res); >> + if (!res->class) >> + goto out; >> + >> + /* If MBA MSCs lack Narrow-PARTID support, roll back. */ >> + cprops = &res->class->props; >> + if (!mpam_has_feature(mpam_feat_partid_nrw, cprops)) >> + mpam_partid_max = mpam_intpartid_max; > > Isn't max reqpartid stored in mpam_partid_max? Why is a rollback necessary? > "In order to be able to assign multiple reqPARTIDs freely to resource control groups, it is necessary that all MSCs that are used by resctrl either implement Narrow PARTID (so that PARTIDs can be remapped explicitly) or otherwise only have controls whose resource regulation is stateless and so whose behaviour would not be affected by splitting a control group across multiple PARTIDs." Best regards, Zeng Heng