From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout01.his.huawei.com (canpmsgout01.his.huawei.com [113.46.200.216]) (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 8211E1925BC for ; Sat, 21 Mar 2026 07:18:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.216 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774077532; cv=none; b=kI+Fn8UFctgs+7qqO/rghrEcma/QSHSslkdfIOumSPR0eVva3kH7zJ4xT07BhpWxwZ2rmFjmnsMstyg0Pk8IReUNACE4I3/wodG7TwLLshIua8nvQsL2lVQVdyVI/qNbBaYzswaoz3Vh8RaYhkPJ9Uu+ik8Pc/PFWnbYqrC0o1E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774077532; c=relaxed/simple; bh=XwLrktmnqLHlMoum+WNgjDmle9GfGgPmi36lDKVWZR4=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=GUj+NUAaG4Kv2GPZxEmyUUWRomOgiEsbRpAExns6raioXNWXGXHL6la3HKcBwJAyYb6g7lSpIBzDQXsd/eYlHBmTB60TWgmNFgaokk3eOrj9CdZDKankhneUilhjEfHwZQYsp8AcKlqkWw/n3Z77grgBEYkBPWOFbuqb3UAieR8= 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=JPrxoUzE; arc=none smtp.client-ip=113.46.200.216 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="JPrxoUzE" dkim-signature: v=1; a=rsa-sha256; d=h-partners.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=FoGJL4CgUEO0xW6iUZSmT7T0akgZGM/Dpklbm6rhiYI=; b=JPrxoUzEvVnpgZ19qb1MbrkroPevojeyNwL3VXy28HqITqyACEFTaJ6c/Vz48nLZ/6dM3CwFI ywATNDPAl7Kb5C/ZF2RkShNq5dCyzFoNo0VjiJRSXgQYkdx8V+0+2JuA+/xQcfgVtZFNveMmJtZ vsp3zgDIDGqCVo2YElsUnwY= Received: from mail.maildlp.com (unknown [172.19.162.197]) by canpmsgout01.his.huawei.com (SkyGuard) with ESMTPS id 4fd9dF1n7Gz1T4G5; Sat, 21 Mar 2026 15:13:21 +0800 (CST) Received: from kwepemf100008.china.huawei.com (unknown [7.202.181.222]) by mail.maildlp.com (Postfix) with ESMTPS id 8BB6D40363; Sat, 21 Mar 2026 15:18:46 +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, 21 Mar 2026 15:18:42 +0800 Message-ID: Date: Sat, 21 Mar 2026 15:18:41 +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 0/9] arm_mpam: Introduce Narrow-PARTID feature Content-Language: en-US To: Ben Horgan , , , , CC: , , , , , , , , , References: <20260317132141.1272506-1-zengheng4@huawei.com> <22cae175-f7ef-4458-8ab6-77b3990616ca@arm.com> From: Zeng Heng In-Reply-To: <22cae175-f7ef-4458-8ab6-77b3990616ca@arm.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: kwepems100001.china.huawei.com (7.221.188.238) To kwepemf100008.china.huawei.com (7.202.181.222) Hi Ben, On 2026/3/21 0:14, Ben Horgan wrote: > Hi Zeng, > > On 3/17/26 13:21, Zeng Heng wrote: >> This series applies on top of the mpam_resctrl_glue_v5_debugfs branch of: >> https://gitlab.arm.com/linux-arm/linux-bh.git >> >> Background >> ========== >> >> On x86, the resctrl allows creating up to num_rmids monitoring groups >> under parent control group. However, ARM64 MPAM is currently limited by >> the PMG (Performance Monitoring Group) count, which is typically much >> smaller than the theoretical RMID limit. This creates a significant >> scalability gap: users expecting fine-grained per-process or per-thread >> monitoring quickly exhaust the PMG space, even when plenty of reqPARTIDs >> remain available. >> >> The Narrow-PARTID feature, defined in the ARM MPAM architecture, >> addresses this by associating reqPARTIDs with intPARTIDs through a >> programmable many-to-one mapping. This allows the kernel to present more >> logical monitoring contexts. > > Thanks for this series and all your help with MPAM driver. Using PARTID > narrowing to allow more resctrl monitoring groups is a good idea. > >> >> Design Overview >> =============== >> >> The implementation extends the RMID encoding to carry reqPARTID >> information: >> >> RMID = reqPARTID * NUM_PMG + PMG >> >> In this patchset, a monitoring group is uniquely identified by the >> combination of reqPARTID and PMG. The closid is represented by intPARTID, >> which is exactly the original PARTID. >> >> For systems with homogeneous MSCs (all supporting Narrow-PARTID), the >> driver exposes the full reqPARTID range directly. For heterogeneous >> systems where some MSCs lack Narrow-PARTID support, the driver utilizes >> PARTIDs beyond the intPARTID range as reqPARTIDs to expand monitoring >> capacity. The sole exception is when MBA MSCs lack Narrow-PARTID support, >> their percentage-based control mechanism prevents the use of PARTIDs as >> reqPARTIDs. > > We also need to consider how this will interact with cache capacity controls > (CMAX/CMIN). Although, they are not exposed by the driver yet. For MSRs that support percentage-based control mechanisms, if Narrow- PARTID is not supported, the functionality needs to be rolled back. The limitation will be included in the next version. > >> >> Capacity Improvements >> ===================== >> >> -------------------------------------------------------------------------- >> The maximum | Sub-monitoring groups | System-wide >> number of | under a control group | monitoring groups >> -------------------------------------------------------------------------- >> Without | | >> reqPARTID | PMG | intPARTID * PMG >> -------------------------------------------------------------------------- >> reqPARTID | | >> static allocation | (reqPARTID // intPARTID) * PMG | reqPARTID * PMG >> -------------------------------------------------------------------------- >> reqPARTID | | >> dynamic allocation | (reqPARTID − intPARTID + 1) * PMG | reqPARTID * PMG >> -------------------------------------------------------------------------- > > Does the quest for more monitoring groups stop here or do you see a usecase > for limiting the number of control groups to get more monitoring groups? > Plan to build upon the original patches by introducing an enhancement that allows users to limit the number of control groups via a new boot parameter, with a range of [1, intpartid], thereby achieving the goal of expanding the number of monitoring groups. Thanks for your review comments. Best regards, Zeng Heng