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 7ECA1EAC7 for ; Sat, 11 Apr 2026 06:33:02 +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=1775889186; cv=none; b=YDvAzF+DNUAtsMHyZ6dxqAxZV7k8hACGcH+OGaYFfhqP8Q7/S4T16QROqrB5mREby7EjewvYqk4buf64aeK2IoH/6U9+NJ4w7JYkPLJJWBpyUbS28M9QugT069/8kP7aYzYbV7EtH6KrcErsU5f6RvjETYh7jM9iwym6fx0SiWc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775889186; c=relaxed/simple; bh=g/nuGdb/tKJmJ1zakdVkBv3U2jr34IuN1cp+4xj42rc=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=gemUHrU5UQxDUEBGs6tALeokAkgtrg5QDg8IwJX1lCAk4qSo02eRSKIXBnyIuPHFWZYA+cb3Og3c3delCNHRYVfwLhl4wRorSwV+xzsLSb7M6hkelcTqEezAnfV6zpm7ch0A5N3bjC8wkm4cdK+NWo9qpl0NZ1lWpuFw/2OWIZA= 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=M+NKg7Gs; 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="M+NKg7Gs" dkim-signature: v=1; a=rsa-sha256; d=h-partners.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=wa1Ro9lX+wk+Y7un/lFHHPtMCJK5negZCzBzyfgMkuE=; b=M+NKg7Gs7DfsTX2KC6lfX7EV8ThZUYaPyKSbBtQHmN1ZlhCMqDryk3Xrf479KB8ZEhIYpPCPC XJr4JNQPYSxT7WeR3PTg2BiHIueutDbwyzsV3UVFfDWbkXizwWLD1uAvzb/aB6FQ1eQUp8WqMrz 5bdmxUphn3mJxgyBeAMsd1Q= Received: from mail.maildlp.com (unknown [172.19.162.144]) by canpmsgout01.his.huawei.com (SkyGuard) with ESMTPS id 4ft3c61Ksqz1T4Gh; Sat, 11 Apr 2026 14:27:02 +0800 (CST) Received: from kwepemf100008.china.huawei.com (unknown [7.202.181.222]) by mail.maildlp.com (Postfix) with ESMTPS id 014B840538; Sat, 11 Apr 2026 14:32: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; Sat, 11 Apr 2026 14:32:55 +0800 Message-ID: Date: Sat, 11 Apr 2026 14:32: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 0/9] arm_mpam: Introduce Narrow-PARTID feature 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-1-zengheng4@huawei.com> From: Zeng Heng In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: kwepems500001.china.huawei.com (7.221.188.70) To kwepemf100008.china.huawei.com (7.202.181.222) Hi Shaopeng, On 2026/4/10 8:13, Shaopeng Tan (Fujitsu) wrote: > Hello Zeng Heng, > >> 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. >> >> 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. >> >> 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 >> -------------------------------------------------------------------------- >> >> Under MPAM, the number of reqPARTID is always greater than or equal to >> intPARTID. > > If reqPARTID % intPARTID > 0, does that mean we cann’t fully use reqPARTIDs? > Some chips have a large number of intPARTIDs, is it possible to use only a limited number of intPARTIDs? Thanks for the feedback. Consider adding a boot parameter to allow users to limit the number of intPARTIDs, and this parameter should satisfy the constraint: reqPARTID % intPARTID == 0 Alternatively, we also provided dynamic allocation of reqPARTIDs. This approach would maximize resource utilization, providing number of monitor groups up to: (reqPARTID - intPARTID + 1) * PMG > > As you know, Arm (Dave) has also implemented the partid narrowing feature[1], > are there aspects of Arm's proposal that do not meet Huawei's requirements? > Also, could you tell me about your future plans? > https://lore.kernel.org/lkml/20250117151033.1517882-1-Dave.Martin@arm.com/ [1] > Huawei does not have any specific requirements or constraints for this feature. When we initially tried to send this patch series, there was no existing implementation of this capability in the community. In addition to the static allocation approach similar to Dave's proposal, we have also provided the dynamic allocation scheme mentioned above. However, this would require moderate changes to the resctrl core layer. If the community has not yet implemented this feature and would be willing to provide review feedback, we are committed to continuously updating and iterating on this patch series for general MPAM hardware platforms. Best regards, Zeng Heng