From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout09.his.huawei.com (canpmsgout09.his.huawei.com [113.46.200.224]) (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 2B4E1142E83 for ; Mon, 2 Feb 2026 09:16:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.224 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770023779; cv=none; b=iCSpapFlpdKjh7Ov0zj+dqLvwuBnMtsV/At6cek0/XW3yWvR+P67giBH68Ry8UeJQnsThblF3OKyAH7nCulwmLjxWAh/fzPxqlLuIZ8Ln7C/YYkahNcmWqo5JKFFjuvAVk1yxtPFA9fZQAge9RE9QH9lunHWPMFcTDs6GBswW8U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770023779; c=relaxed/simple; bh=wTKZ5lW55KIJw9GZvyTwaLhhhvQWg1ow4WsdXT1j5Qc=; h=Message-ID:Date:MIME-Version:Subject:From:To:CC:References: In-Reply-To:Content-Type; b=ZbftNi2bAiwWGmWHdPInCm3xFXzNIRlXw8FZSyz74MUbhy7VanL/wqOAVJEIZq8AFZ91UEdkguHTXxpMOMTgi0J2NpSLnuaA1r2mFVbn1SOyCrHf5LLzBs7W6EnvtmY/hKp1FjMypy3jSsu+9LPa+K/NBWz66vSdlOpiHiezV3Y= 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=UKr2QTpQ; arc=none smtp.client-ip=113.46.200.224 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="UKr2QTpQ" dkim-signature: v=1; a=rsa-sha256; d=h-partners.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=4ZdEko1dNxGMMnx5kzsm9rQt09NeKqA9jefrNI48VNU=; b=UKr2QTpQV0QNmsgOXdKwfjLIETAJxFw1nWP5iUs3t+aJmJG3FyxvT8zr/6siL889jrOzNzqFL Wd7Y0oC2tUVrxbCjuzCr/h+204Hd5/aSlHIG38iQKiMgHx1PxBiMvOAzz2cQvlLA4OX4kTJkGz8 TI8EwhaBX/TTIl/Nrn83Jb8= Received: from mail.maildlp.com (unknown [172.19.163.15]) by canpmsgout09.his.huawei.com (SkyGuard) with ESMTPS id 4f4LTK3rPkz1cyPZ; Mon, 2 Feb 2026 17:11:33 +0800 (CST) Received: from kwepemf100008.china.huawei.com (unknown [7.202.181.222]) by mail.maildlp.com (Postfix) with ESMTPS id 2EA3340539; Mon, 2 Feb 2026 17:16:06 +0800 (CST) Received: from [10.174.178.24] (10.174.178.24) 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, 2 Feb 2026 17:16:05 +0800 Message-ID: Date: Mon, 2 Feb 2026 17:16:04 +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] arm64/mpam: Support partial-core boot for MPAM Content-Language: en-US From: Zeng Heng To: Ben Horgan , , , CC: , , Jonathan Cameron References: <20260107031336.3599175-1-zengheng4@huawei.com> <29a433ac-3247-f3f1-323e-70187c76f46a@huawei.com> In-Reply-To: <29a433ac-3247-f3f1-323e-70187c76f46a@huawei.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: kwepems500002.china.huawei.com (7.221.188.17) To kwepemf100008.china.huawei.com (7.202.181.222) On 2026/2/2 16:41, Zeng Heng wrote: > > > On 2026/1/29 18:11, Ben Horgan wrote: >> Hi Zeng, >> >> I think I've just managed to whitelist your email address. So, all being >> well I'll get your emails in my inbox. >> >> On 1/7/26 03:13, Zeng Heng wrote: >>> Some MPAM MSCs (like L2 MSC) shares the same power domain with its >>> associated CPUs. Therefore, in scenarios where only partial cores power >>> up, the MSCs belonging to the un-powered cores don't need and should not >>> be accessed, otherwise bus-access fault would occur. >> >> The MPAM driver intentionally to waits until all MSCs have been >> discovered before allowing MPAM to be used so that it can check the >> properties of all the MSC and determine the configuration based on full >> knowledge. Once a CPU affine with each MSC has been enabled then MPAM >> will be enabled and usable. >> >> Suppose we weren't to access all MSCs in an asymmetric configuration. >> E.g. if different L2 had different lengths of cache portion bit maps and >> MPAM was enabled with only the CPUs with the same L2 then the driver >> wouldn't know and we'd end up with a bad configuration which would >> become a problem when the other CPUs are eventually turned on. >> >> Hence, I think we should retain the restriction that MPAM is only >> enabled once all MSC are probed. Is this a particularly onerous >> resctriction for you? >> > > I have no objection to the restriction that "MPAM is only enabled once > all MSC are probed." This constraint ensures the driver has complete > knowledge of all Memory System Components before establishing the > configuration. > > > However, this patch is specifically designed to address CPU core > isolation scenarios (Such as adding the 'isolcpus=xx' kernel command > line parameter). > > The patch allows the MPAM driver to successfully complete the > initialization of online MSCs even when the system is booted with > certain cores isolated or disabled. The patch ensures that MPAM > initialization is decoupled from the requirement that all CPUs must be > online during the probing phase. > > CPU core isolation is indeed a common production scenario. This > functionality requires the kernel to enable functionalities in the > presence of faulty cores (which cannot be recovered through cold boot). > This ensures system reliability and availability on multi-core > processors where single-core faults. > > Without this patch would prevent MPAM from initialization under CPU core > isolation scenarios. Apologies for not mentioning in the patch: we can > verify the functionality by adding 'maxcpus=1' to the boot parameters. > > Please let me know if you have any further questions or concerns. > > > Best Regards, > Zeng Heng > > My platform consists of 12 clusters, each containing 16 CPU cores. Under normal boot conditions, the schemata is as follows: # mount -t resctrl l resctrl /sys/fs/resctrl/ # cat /sys/fs/resctrl/schemata L3:1=1ffff;26=1ffff;51=1ffff;76=1ffff;101=1ffff;126=1ffff;151=1ffff; 176=1ffff;201=1ffff;226=1ffff;251=1ffff;276=1ffff Adding 'maxcpus=1' to the boot parameters: Without this patch, MPAM initialization fails. With the patch, MPAM initialization succeeds, the number of clusters matches expectations, and the schemata is as follows: # mount -t resctrl l resctrl /sys/fs/resctrl/ # cat schemata L3:1=1ffff Thanks, Zeng Heng