From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout10.his.huawei.com (canpmsgout10.his.huawei.com [113.46.200.225]) (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 F10943A6F02 for ; Mon, 13 Apr 2026 09:12:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.225 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776071583; cv=none; b=O40+dHk0+6Vps0DBx2OOwoQqlR9SyytHzL2EBsCZpIuxLBqYmotzw2tbpVuJAKVujdP8qT7W59i4VPkDZ115S/FtRVLzCFx2pnUe5C2fgwSiKAPLj90ezh9Ex4Keu+bWbzDguAkB7oKt5xTDh09+Fk33s80eM5qOMYV+Qj+ufQs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776071583; c=relaxed/simple; bh=kdOGN0PsPj7yXYegiPBsENMJ99kG0PMQfPqeuAK20x8=; h=Message-ID:Date:MIME-Version:Subject:From:To:CC:References: In-Reply-To:Content-Type; b=HbOnjM4DMzu3HD8Od3mjb+CTjSIWNdSE38nQHN9Wt3uZH5dDeFtf+vksEYuRf9nf5gJn+k9A24J0TyRnEuOSEsIjdCgm5WB6LsBCSJZ4X5kzGqwU6Uw6oYZSt9nyD4d2JKfoaJc52m236s3Hv9bnyohKknkmWzdNf0GB3/byE8c= 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=BR4TpXZq; arc=none smtp.client-ip=113.46.200.225 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="BR4TpXZq" dkim-signature: v=1; a=rsa-sha256; d=h-partners.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=6dNLbAOm0GQunG+PQCBwrb0oAZPSU08Anl3bRCOzoPE=; b=BR4TpXZqW05tnKUvV7HiaWTlHB3aBIH8xYn8wOFfl/h8hqmxpHLqQTQtZH+tStPXEMefVlzJl fpH/7G2eoZfDqs2NVNXI6Fj9XDXb/UfiFZ8nx2ttIORbNMOBMBetALM9w7Kqu+dYPmdO0kXM6mx 3ZXtu0WL25TK7Nmiy2NhQnk= Received: from mail.maildlp.com (unknown [172.19.163.15]) by canpmsgout10.his.huawei.com (SkyGuard) with ESMTPS id 4fvM3Q4ngfz1K9CS; Mon, 13 Apr 2026 17:06:42 +0800 (CST) Received: from kwepemf100008.china.huawei.com (unknown [7.202.181.222]) by mail.maildlp.com (Postfix) with ESMTPS id 7E74B40571; Mon, 13 Apr 2026 17:12:57 +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; Mon, 13 Apr 2026 17:12:56 +0800 Message-ID: Date: Mon, 13 Apr 2026 17:12:55 +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 From: Zeng Heng 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> <30d37733-db55-f29f-5bbf-1b69ed0846e5@huawei.com> In-Reply-To: <30d37733-db55-f29f-5bbf-1b69ed0846e5@huawei.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: kwepems200001.china.huawei.com (7.221.188.67) To kwepemf100008.china.huawei.com (7.202.181.222) Hi Shaopeng, On 2026/4/11 14:50, Zeng Heng wrote: > > > 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." > > I've rewritten the commit message in an attempt to explain this more clearly: https://lore.kernel.org/all/20260413085405.1166412-4-zengheng4@huawei.com/ Thanks for your review in advance, Zeng Heng