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 957291DDE5 for ; Fri, 20 Mar 2026 16:14: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=1774023295; cv=none; b=puu9lHNmVpAk822ekbiGhvb4HfrKOQBiOAT4I6n4RTUlnytC46REkT49rJRAHybbkS4P3NDMa0ZgQ9q8LwxqCRgM9EFxfC5UjhD6Gby/Dy9Byvv5ZVgPiMT3FnYrLsnMgcDUs2WFRR4fe/H8PKjIv8rte2T7aIZzRq1ghpCxd+Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774023295; c=relaxed/simple; bh=LbLqhF9jMi2cSbksLgoG808t+nFHm6mmF6f3z4gJvYE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=b+qLBwlwPl0cHNTJItU2OzCPbKR/wtJWWTsBmEObV9oCFMqazxT4a93oqzq8A35VQFO6CA3KGCf8nqof0mk/66xxzDqfma3FtyIdmuXReRawX7azcwdv4kjXkyVk+AsO+6Pht3XssgfmMXjN/hynmqczYH4PQaAIjUjL7WOz4Hk= 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; 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 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 02CEF165C; Fri, 20 Mar 2026 09:14:47 -0700 (PDT) Received: from [10.1.196.46] (e134344.arm.com [10.1.196.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5D86B3F7BD; Fri, 20 Mar 2026 09:14:51 -0700 (PDT) Message-ID: <22cae175-f7ef-4458-8ab6-77b3990616ca@arm.com> Date: Fri, 20 Mar 2026 16:14:41 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Thunderbird Daily Subject: Re: [PATCH v3 0/9] arm_mpam: Introduce Narrow-PARTID feature To: Zeng Heng , 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-1-zengheng4@huawei.com> Content-Language: en-US From: Ben Horgan In-Reply-To: <20260317132141.1272506-1-zengheng4@huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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. > > 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? Thanks Ben