From nobody Sat Sep 26 03:17:25 2026 Received: from PH0PR06CU001.outbound.protection.outlook.com (mail-westus3azon11011026.outbound.protection.outlook.com [40.107.208.26]) (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 689553C141A; Fri, 4 Sep 2026 18:07:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.107.208.26 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788545266; cv=fail; b=EfmTvngXQZPmfmMMH0na/LYDZZxsMueTirW4LT5+XUf8Eo8LdBKjSgV1DKr3a/qYehqy2EJng8zrqdE2sB1zI8lPI72GGrfNrgMFaabdCTmOjhca9hwiuqP6oxxCU7sbKA9rSyfz6mK7/NHHXps2c6ciSmcJcoKrb+lV07uqZSo= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788545266; c=relaxed/simple; bh=mk1KDE75BCXyDMWVVtHZqlQdP/olPpD16oAyc3wjU6I=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=XMMVquNt7PDpbv3XOPkWZJ0HwF7cF+rBTzug74ESJayuSuaYrZbK0bVr+RZmWeqPLbWOXXJI5FsR9TYL+mvAro+WbYOnL73irLK6OUqgCrF5+czCMnNvXc9jQwhgSYt+ogn/d0FqwLsWMZgwDgL8dfLQCJWiMIRmG1eTL54pnNM= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com; spf=fail smtp.mailfrom=amd.com; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b=2ajCHFiD; arc=fail smtp.client-ip=40.107.208.26 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=amd.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b="2ajCHFiD" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Tfvf9LjNC1XL46PFIZBgk0/r2otW31o0CYCKNB0vbYhRbg5hK3He27nomNuiEh8vsUexC063VUBVlKbq9PDycDev0SaxHmuHys9iEzX9PbOWJ+qOz4SIl0DhqAaMnm/TnH9a9KH9pbLGwe4qL/hrjbUiVkdQ2oYz8jLwXyY4BBRR4+L3ZUH64viBO8i/8N3JTeKaZ5FE0h/cpqXW+cUHx8eZXWRquDtWVMAjyCqeXyQWlo5G+Butv8IVZWutXaZrsubvscvmwkcmOsah1tUkpVH4QZdL+vEDdK0gNp+tCYtDLHdnSd/Px5opV0nao8P/XDE1y9sHtYi7W6CKdZcxOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2Ag6bX2i/hvcm+y0zwqzRVUmJnGNbvqRWHc8OhRuhpY=; b=uVdam8W1tIKV1uaePUaQs1jhNUNmxeo/UZD3mN9Lt8zyD3zlalzMU7hWYN7qfqhNNckxeJVoFPh9VO5zc6Pgn56vRM+GXCI0PfE7S0yrRhl8UTuhDkMlH05/Uu2vdw5OiZMrE1Rm9OCa5iHeSB08nE3GoOXrasRvMAtQkdtx5R94aPMSyLGcvAeJ0/T1Ve3m1MJCJa77EgeWktu+Ez0mw1z5nXkHhLIMYJdm+9wUVAfGdbKqQEswUZG27E6bix61rwmE+thozPfnICqHL/Prg638NOOZjd4YKxkl45SFqVh2rAaaZYi7hMGdS/qP/xEAmBjHCoKUO8Wf+JVs7+zSeg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=intel.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2Ag6bX2i/hvcm+y0zwqzRVUmJnGNbvqRWHc8OhRuhpY=; b=2ajCHFiDTByfQR/nHInS1Fr1aWuY8DeAwWYpfGnOfw/ta3SLFZ7UW8eqPjH4Rf0Mwsd2fpK8U3KcDRywr/AJLDs00bJ0LGSH92PxckNUFi7nV5bSzeS5kRbkmqRD3V8s1/8t60wbYbBMSqEXJ95d+cSydImGQ7tzMH2wFZD+kAs= Received: from BN0PR08CA0026.namprd08.prod.outlook.com (2603:10b6:408:142::28) by IA1PR12MB8519.namprd12.prod.outlook.com (2603:10b6:208:44c::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Fri, 4 Sep 2026 18:06:25 +0000 Received: from BN7PEPF000000A1.namprd04.prod.outlook.com (2603:10b6:408:142:cafe::1d) by BN0PR08CA0026.outlook.office365.com (2603:10b6:408:142::28) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.13 via Frontend Transport; Fri, 4 Sep 2026 18:06:25 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Received: from satlexmb07.amd.com (165.204.84.17) by BN7PEPF000000A1.mail.protection.outlook.com (10.167.248.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.8 via Frontend Transport; Fri, 4 Sep 2026 18:06:25 +0000 Received: from bmoger-ubuntu.amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Fri, 4 Sep 2026 13:06:24 -0500 From: Babu Moger To: , , , CC: , , , , , , , , , , , , Subject: [PATCH v2 1/3] x86/resctrl: Fix ABMC counter programming for extended counter ranges Date: Fri, 4 Sep 2026 13:06:10 -0500 Message-ID: <9e85f67add9ac84f55e4b0fced92ed8994f8419a.1788545152.git.babu.moger@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN7PEPF000000A1:EE_|IA1PR12MB8519:EE_ X-MS-Office365-Filtering-Correlation-Id: 055ed391-5a61-4195-eef4-08df0aaf3c3f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|1800799024|376014|7416014|23010399003|36860700016|6133799003|10067099003|3023799007|11063799006|56012099006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: tXPFIsCmtJOmsXDMbyxAkcmW2Hb5ZJShnIxOje/3+qjHmHGHnQh4glVShNVecy+yGESEarevX5gedmqGU5EMWCEtFoh4OmvTWAF6us//GAJXPGwOhcV81rUd/dOpE4ft3K14ZTrRp8f5hD+jtT8bHHbrBhJpiIDjzoL8CjaB63jl9pKS6TDdX2N1ZoX4qL8E5cYqhpBI9MdF/8YpQ0Zlk0ANTSaGke7ksC4ul5U/+D+IAPduwA9peGM9phVntado1jZVtK7ZB9XZYnK9qFOvk57pjHO6+xobRGU2a2UZ+Ui1QxcRJ8/pQrUm7jc8yOCPDRnBcunGNsDPcHUhqO08g2DdN8yPABErI7+f/BTLZtbFpPZauNwauUWA0CJ9Op0ueru397JH1C8eRKRzh49OqD6cqa5PTvBLXw4zJ5wph6GVsWsmXFrEnlv3ES0OMWzhTNPYHuW/Oh3K4QoMkthOOid+eIbWAKShmArpo3bDE/sd4JraYef+IVLIZfDrwbHwuITkdsDwnFHzSUFtasMFu/hl3T4mWEOgbbnB3XYTw+x9M0FuN/ZY7qdDxxNww+Unp26k4Xf6L/YWqOqQwFixjBehlDiXYSYmbtXeISTmk9yrA0RpIAUUj4ZM96QDx6AY4GRObfSKFnxZNjLuOzlapK2lTS4RCu6OeFyHHwUTwJfaYtOrXBxy4o9QdOBYkcikkjN71Hr9wP/qi9uvknxLmQ== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(376014)(7416014)(23010399003)(36860700016)(6133799003)(10067099003)(3023799007)(11063799006)(56012099006)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: IesNCLCS3poCfFx0Nk3WUQF67Shd2OxbcUdUJ0vJQSYnT7aoBIWOzncEBxsj95CafW6bHvg8zrAqsLjPqUoebLWVd7IEPsPMXB8lkArcY9ZQu821PGwcQiE7ycSP+Wj1sH43I51T/oqe7gZdstIUvu3oFP1QAT72sGzEvi/xvvrv6zXQQ/wAgvPJ7v0Zli2JQpVSlm6xIcQD8I+pkbydYzDqhM8nPU/zd1NCCz3jTs0sQud7QqANlKuCE4XiwTNQHpBZo9XtJcwx5Z4bLtUQdohKiquqzr5t+Wbwdj56r84+cB+AELkEWj2zFKoioEpuAp/Cu3JD6t4zI8qW5rbIUvQhEmRLojYLiIUXXlsudHgKD6AhCWsnXaKrzJ6CD4bSK72to7/1aN41meJ1uogCdVdLCZ4JZ/PBZPJY2Hix0lgL6GbKb8Vj1u5dAwWw70J2 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2026 18:06:25.5855 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 055ed391-5a61-4195-eef4-08df0aaf3c3f X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN7PEPF000000A1.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB8519 Content-Type: text/plain; charset="utf-8" Memory Bandwidth Monitoring (MBM) can report incorrect values when ABMC is enabled on systems supporting more than 32 ABMC counters. As the number of active monitoring groups increases beyond the range supported by the existing counter ID encoding, programming an ABMC counter may inadvertently affect a different counter, resulting in unexpected counter resets and abnormally large MBM readings. The issue originates from the ABMC counter programming interface in the L3_QOS_ABMC_CFG MSR. The counter ID field is currently defined as 5 bits, which limits the addressable counter range to 32 counters. On systems implementing more than 32 ABMC counters, counter IDs above 31 cannot be encoded correctly. Consequently, programming a counter ID beyond the supported range may target an unintended counter and reset bandwidth statistics associated with another monitoring group. While updating this logic, it was also observed that the bw_src field, which encodes the RMID, is currently at its 12-bit limit with support for 4096 RMIDs. This field also needs to be updated for future expansion. Also found one more pre-existing issue. This union structure can truncate data on 32-bit x86 systems when unsigned long is used. Fix the issues with the following changes: 1. Update the cntr_id field handling to support the full hardware ABMC counter range and ensure that counter programming does not interfere with unrelated counters. 2. Expand the bw_src field to 15 bits. 3. Change "unsigned long" to u64 to fix truncation on 32-bit x86. The AMD64 Architecture Programmer's Manual [1] available at [2] will be updated accordingly in a future revision to document the expanded cntr_id and bw_src field definitions. [1] AMD64 Architecture Programmer's Manual Volume 2: System Programming, Publication #24593, Revision 3.41, Section 19.3.3.3 "Assignable Bandwidth Monitoring (ABMC)" Fixes: 84ecefb76674 ("x86/resctrl: Add data structures and definitions for = ABMC assignment") Signed-off-by: Babu Moger Link: https://bugzilla.kernel.org/show_bug.cgi?id=3D206537 # [2] --- v2: Moved the link tag to the last. v1: https://lore.kernel.org/lkml/980f39d3a0e0d9f73925e362f835aeef070a1bc5.1= 784322818.git.babu.moger@amd.com/ --- arch/x86/kernel/cpu/resctrl/internal.h | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/arch/x86/kernel/cpu/resctrl/internal.h b/arch/x86/kernel/cpu/r= esctrl/internal.h index e3cfa0c10e92..b3d780eda8a7 100644 --- a/arch/x86/kernel/cpu/resctrl/internal.h +++ b/arch/x86/kernel/cpu/resctrl/internal.h @@ -192,7 +192,6 @@ union cpuid_0x10_x_edx { * @bw_type : Event configuration that represents the memory * transactions being tracked by the @cntr_id. * @bw_src : Bandwidth source (RMID or CLOSID). - * @reserved1 : Reserved. * @is_clos : @bw_src field is a CLOSID (not an RMID). * @cntr_id : Counter identifier. * @reserved : Reserved. @@ -210,16 +209,15 @@ union cpuid_0x10_x_edx { */ union l3_qos_abmc_cfg { struct { - unsigned long bw_type :32, - bw_src :12, - reserved1: 3, - is_clos : 1, - cntr_id : 5, - reserved : 9, - cntr_en : 1, - cfg_en : 1; + u64 bw_type :32, + bw_src :15, + is_clos : 1, + cntr_id :12, + reserved : 2, + cntr_en : 1, + cfg_en : 1; } split; - unsigned long full; + u64 full; }; =20 void rdt_ctrl_update(void *arg); --=20 2.43.0 From nobody Sat Sep 26 03:17:25 2026 Received: from BL2PR02CU003.outbound.protection.outlook.com (mail-eastusazon11011061.outbound.protection.outlook.com [52.101.52.61]) (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 C8CFA511230; Fri, 4 Sep 2026 18:06:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.52.61 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788545202; cv=fail; b=rVd+8LNHqh4G5SnNyLrNUA4XOvgmNBtLcGzHgT8vGyOlhClDuyNl/uMAna5WoSOR9Td1uB8+0vodSO37gEzS1JHQVS2jmmRWzf4kXbOmVPpy76SgbXGLs4fyP3AJAMjwNJ2jsj9bJd8vIgQg+vhca5VRcSL2kN0owRKV96sBYSQ= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788545202; c=relaxed/simple; bh=W7l100rmkoykVgKApgbjtzFhzX4034PvXPIAZao17RY=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=TitfsHzS/KkUHjLBkTzabj3bzYzYVulcVFt8zUhfo1aWnDME5CzsFGsrHMBlq1bwOx5wgtgEA3W+klYmaDcExNHdZsY7sla/DlnALL1nwNJJ/33aSiPgI4SchIY0Yu+aNNu+nhGcItf15DB5o3v0A/013p5Zc9Ae5up4G3jWOeU= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com; spf=fail smtp.mailfrom=amd.com; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b=PpffhhtS; arc=fail smtp.client-ip=52.101.52.61 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=amd.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b="PpffhhtS" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=JkpmDW323nsz84WxEyyx9t0FBm2K8M93SOsl9jrQCA2CV/Bzm30MzAvPj1xS1dLf2CmSpWwV/cgztIb4xv2Oofnxs4Vcsq2ywO9XlcIrdsysSGokHF4jMIW0t0A/KsEWgmCZVR2xbfUE6NVwve6bdUPR1RCmGsEhzrMILlw4A0+v5EQRPswG1Jv7ygXrXB4nwdKbbQZdfS5FCkLWybhG63cNUiOYqQ8utNyRHkt9uJ6wSh85ytHtlIUeCqPBeuHgC+WBY2LbTNQPlGCU1kMY8S2LwWyDGAAgx+VtZvZ7zAEViQjqgYHJAp4IDW1d6LROwDpBl+KCHbhuHW/hzoxgTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+y5B48+5hf2I7zAcU6TRpWa20HG8b/HWbmpu14d50Lc=; b=vNn5CnDkOfFswvQYaRAeHMa2Qn6evZ4nCuVdhaRIkAg2+H+7eM9GivioZzFjJobm2kEG5IlkP2wbHwT5m88pdHEAckMr+t/9+9nAKwi8UPIMRfn1QKRAoYnZio3/BvBmev2XcW/SONfUzu4bnjyZ6DqUi7FlyUnw7gvcHjrEUWgOsg2oVTWxxqdgSZEE31z4hBNAlIlZl5pP846+svIpT2dr+clv1dLbH+UnqMSvdpIct/YdZ6Z0wyy1mfYahntkXN78k21DAjgTDpIbwzRe+lI8n6Uw3Ibtk/DhB8q/NgC+HWK1viItRn5PFCFFRQlgW/qvRq+E7i3eD/R1zQ2IcQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=intel.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+y5B48+5hf2I7zAcU6TRpWa20HG8b/HWbmpu14d50Lc=; b=PpffhhtSPYxkN6D/bXPPocheNmeB0NZr/aq4Zcb8asaBtYoNLmhuC2bCYk7OoVSkoI31FaPjBOdehax8UTE1OpGL0zxK725nz2yOI8Vj/WPAjnyq+UKSSkvbtDg/IiCr2M0P+Ied+psQnq7rVQr1oF3ZR2+Iz+6zHSU7Rx8ANcQ= Received: from BN9PR03CA0559.namprd03.prod.outlook.com (2603:10b6:408:138::24) by SA5PPF916D632A9.namprd12.prod.outlook.com (2603:10b6:80f:fc04::8d6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.10; Fri, 4 Sep 2026 18:06:36 +0000 Received: from BN7PEPF0000009E.namprd04.prod.outlook.com (2603:10b6:408:138:cafe::28) by BN9PR03CA0559.outlook.office365.com (2603:10b6:408:138::24) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.360.13 via Frontend Transport; Fri, 4 Sep 2026 18:06:34 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Received: from satlexmb07.amd.com (165.204.84.17) by BN7PEPF0000009E.mail.protection.outlook.com (10.167.248.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.8 via Frontend Transport; Fri, 4 Sep 2026 18:06:34 +0000 Received: from bmoger-ubuntu.amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Fri, 4 Sep 2026 13:06:31 -0500 From: Babu Moger To: , , , CC: , , , , , , , , , , , , Subject: [PATCH v2 2/3] fs/resctrl: Assign counters to existing groups when enabling mbm_event Date: Fri, 4 Sep 2026 13:06:11 -0500 Message-ID: <79d6aaedbef7e3113a15c79b1f6eb7510b2a2a62.1788545152.git.babu.moger@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN7PEPF0000009E:EE_|SA5PPF916D632A9:EE_ X-MS-Office365-Filtering-Correlation-Id: d1ca9c06-3e60-4550-8999-08df0aaf4146 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|36860700016|82310400026|376014|7416014|1800799024|10067099003|6133799003|18002099003|22082099003|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: DzthDQ7JopDG0Kem6RmWrT88Kb/nmSc4T5SEP5k8IL9muAnrL72jLFy7SRxPX1g1mwb+tkq+WQJx+uXRVIt7scrN6O83TajeKmCN4Wx9RXe83knXxUMTsD/XqhAdgejweYHpvf/fJm4l7k5R301j1xED0xIu16yF1kgpGDxGf8fSIKFDT4P318KP4X6ZdxruWOy9Wu5CNL/OUs4LUs3ic7QNywUlNB6mYS/VMewx1rYv1/YyvVv4ZSxOSkZH3dZGaX8BgaRpS4kIiKcQkBta+vko+lQQISWPRoiQMtcyDUFa/AK1pHtgsJKMsGLzJR8cGi8J58jocN5ccUBqXzBCP8o7Iw/CGh1qAOhg0DVIhvAXcy+CGiWL8kgdd/zSTeczBilfHn/0zYVb5NmD5BgDDfgBVUYamDUARtAkljUoaF9+EmwbzoBLMfxOMw4/Vut19ZNq16+mCJG7okNGmW2LsUVQFDhEEw1pcyCdy0YydfPaXbP+bmgBzqkdi97gwta6WetCsJR0yOsYToValQS6bYa8qeEkku2ugoqszTpFnDdxylXrCLqjIhAKD3VtroJpF4kZQR1AWQ8jyQp7kVu31lZVpk+VCbgXFC7UBKyvEDQsnUzdIGx9r+lgJglb60urBc5w14qwFRXp9iyJzkDhug== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(23010399003)(36860700016)(82310400026)(376014)(7416014)(1800799024)(10067099003)(6133799003)(18002099003)(22082099003)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 6hA9AHlyEVsY+e3P1hVLDY4/Yi0EbX59jkS1oR5EKXExX0wI0ieKm0Ic7MW/UXg9DJaOsBVE9hkrYs5Of8usNbeby99lLGf1CEOmOI2UQQqkJWVRKUilE+vXveLc/Dw7bt9joItIX2LCXyueHG9KveOGaEp6pL6vT49IZtmIgWKUc5Rp4JhyyCYWzqRL3lrl+1Fns7lNSisp7aH+xI2HZSFx+Vsr4xL1zxLcS76VHNt7onQnxgqRI2wmTOwLMSr/EpPqnjIXXtWBt1yL22BCcZmVx3wNcUVB99W2ct3yBvwRVw2UQ5OL5evQWYGZ3TMEjTm7w+OqhY0RkFllNcixsQgzf2rt0uk1QVY1nAhvcP4/RfmL1WXrmZhWzUnsCcAEVIjbPRYfov/4rYVlju8nJgupqGYfv4UmKAiUFlso0w3hW/sDjM3Ff3rcGYAEdcDV X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2026 18:06:34.0166 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d1ca9c06-3e60-4550-8999-08df0aaf4146 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN7PEPF0000009E.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA5PPF916D632A9 Content-Type: text/plain; charset="utf-8" resctrl_mbm_assign_mode_write() frees all counters and sets mbm_assign_on_mkdir for subsequent mkdir, but does not assign counters to groups that already exist, including the default group created at mount. Those events then read "Unassigned" until the user assigns counters by hand. Enable mbm_assign_on_mkdir and assign counters to existing CTRL_MON and MON groups with resctrl_assign_cntrs_allrdtgrp() so the switch matches mkdir auto-assignment. Groups left without a counter still read "Unassigned". Update Documentation/filesystems/resctrl.rst to describe this. Fixes: 8004ea01cf63 ("fs/resctrl: Introduce the interface to switch between= monitor modes") Signed-off-by: Babu Moger --- v2: New patch. This patch addresses the Sashiko comment about documentation issue where counters are not assigned automatically when mode is switched to mbm_ev= ent. https://sashiko.dev/#/patchset/8cb66e18e32e4087a9712c1e68ee6da614efe244= .1784322818.git.babu.moger%40amd.com In fact, it exposed a real issue. When switching to mbm_event mode, exi= sting monitoring groups should be assigned counters whenever counters are ava= ilable. This provides a smooth transition between modes and aligns the behavior= with the existing auto-assignment mechanism. --- Documentation/filesystems/resctrl.rst | 7 +++++-- fs/resctrl/monitor.c | 30 ++++++++++++++++++++++++--- 2 files changed, 32 insertions(+), 5 deletions(-) diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesyst= ems/resctrl.rst index e4b66af55ffb..79feeb1dc296 100644 --- a/Documentation/filesystems/resctrl.rst +++ b/Documentation/filesystems/resctrl.rst @@ -371,8 +371,11 @@ with the following files: of counters available is described in the "num_mbm_cntrs" file. Changing = the mode may cause all counters on the resource to reset. =20 - Moving to mbm_event counter assignment mode requires users to assign the = counters - to the events. Otherwise, the MBM event counters will return 'Unassigned'= when read. + Moving to mbm_event counter assignment mode enables "mbm_assign_on_mkdir"= and + assigns counters to the events of all existing groups, including the defa= ult + group, for as long as counters remain available. Events left without a co= unter + will return 'Unassigned' when read until the user assigns one using + "mbm_L3_assignments". =20 The mode is beneficial for AMD platforms that support more CTRL_MON and MON groups than available hardware counters. By default, this diff --git a/fs/resctrl/monitor.c b/fs/resctrl/monitor.c index 73413cb128ea..61463741b91b 100644 --- a/fs/resctrl/monitor.c +++ b/fs/resctrl/monitor.c @@ -1326,6 +1326,27 @@ void rdtgroup_assign_cntrs(struct rdtgroup *rdtgrp) &mon_event_all[QOS_L3_MBM_LOCAL_EVENT_ID]); } =20 +/* + * resctrl_assign_cntrs_allrdtgrp() - Assign counters to the MBM events of= every + * existing group. Called when "mbm_event" mode + * is enabled. + * + * Groups created while in "default" mode have no counter assigned, includ= ing the + * default group created when resctrl is mounted. Assign counters to them = so that + * enabling the mode leaves the same assignments that mkdir would have mad= e. + */ +static void resctrl_assign_cntrs_allrdtgrp(void) +{ + struct rdtgroup *prgrp, *crgrp; + + list_for_each_entry(prgrp, &rdt_all_groups, rdtgroup_list) { + rdtgroup_assign_cntrs(prgrp); + + list_for_each_entry(crgrp, &prgrp->mon.crdtgrp_list, mon.crdtgrp_list) + rdtgroup_assign_cntrs(crgrp); + } +} + /* * rdtgroup_free_unassign_cntr() - Unassign and reset the counter ID confi= guration * for the event pointed to by @mevt within the domain @d and resctrl grou= p @rdtgrp. @@ -1599,9 +1620,6 @@ ssize_t resctrl_mbm_assign_mode_write(struct kernfs_o= pen_file *of, char *buf, (READS_TO_LOCAL_MEM | READS_TO_LOCAL_S_MEM | NON_TEMP_WRITE_TO_LOCAL_MEM); - /* Enable auto assignment when switching to "mbm_event" mode */ - if (enable) - r->mon.mbm_assign_on_mkdir =3D true; /* * Reset all the non-achitectural RMID state and assignable counters. */ @@ -1609,6 +1627,12 @@ ssize_t resctrl_mbm_assign_mode_write(struct kernfs_= open_file *of, char *buf, mbm_cntr_free_all(r, d); resctrl_reset_rmid_all(r, d); } + + if (enable) { + /* Enable auto assignment when switching to "mbm_event" mode */ + r->mon.mbm_assign_on_mkdir =3D true; + resctrl_assign_cntrs_allrdtgrp(); + } } =20 out_unlock: --=20 2.43.0 From nobody Sat Sep 26 03:17:25 2026 Received: from CH5PR02CU005.outbound.protection.outlook.com (mail-northcentralusazon11012069.outbound.protection.outlook.com [40.107.200.69]) (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 1F2B751A740; Fri, 4 Sep 2026 18:06:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.107.200.69 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788545208; cv=fail; b=b3nMIB0Np029/AtVtT/z/HT0YoTXBw0ov94zL1whaWirTHnt7rPa6e6Q/Tqnv7PxQoxSoWel+yEeIPg/UCodcs+1bA+FT1vtH08rrJ3Ny085vz0hmoArsf0qtrcW/r18xrmFutMC1kpXYzyZih+ttZbHatsJ4WM15tpkH644xSo= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788545208; c=relaxed/simple; bh=dyAcIx1fJZZu2LsDQWj7CEf7IGq0Lj6ShAmm4vpYcbU=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=MOfzFORMTpjKzH6Q9UnCUefN/NaLapW02NVTTa6exVNGLUOz86xE7DgiR1mKIZubOI/kw8Zsnneo3uSo5wf4Yr/CF8/P8e6dcshZlIdQacSBbdXbtr3wAaQVU8HB4SlAY6Hg+C/9TaznfestRSwSYeE7Tl0qGpdO+OS9lsbqRH4= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com; spf=fail smtp.mailfrom=amd.com; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b=QwSAdJhl; arc=fail smtp.client-ip=40.107.200.69 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=amd.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b="QwSAdJhl" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=u+DMNxJMN3m/nPQ7y+H3TtKamQcl1nKeLH5F603CssHFPzxSjDESTttSOlMNyXxHxpUhFWeL4K8k1gOeojJ9Nd8gEztF4mKrkDvS614DzS8IHeFzJ7E4F1PVwTK+kPA1hkP+j9OQOMXrkNBI3ym9Vy/XxJxI+8GyaNRh3y6ulooTiZoEuirc3bBeKyUkqfmgorlXZee1vVH+hoeL3MeCLwy3DpAOQ5Dww/gIcCvgmj3QzlNi2q96WafTvOWoVRzcPhro0xc0SCjjKOorjCu9E13PycJaWYp9Yv14pO7uulUYvppuUwYMsBx5GI36gQ9V7Kk2J6TZfQwirwXeURFKdA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hesYsjRcJDr0sDWp2Zlanbd+B0YVGF12dJ+EChCSS3c=; b=HLkWzjCx0dmxKUmS3Cuf1Tzm3XM2hKjX6JbXm+/LOMbLnMmqQSIUxJLL78Clciy1oyDD6cW40CyQb5AeHVcStP/g0+/H7dLwU02l2VVtTfDTblUy6PGVnhOPkcCt1af/oa6HBfq4Z6BV4rd+fSzkN9IRC46XABYKW3sTZZJ8/tntJW934/zIaU3856xZ+nA1h3OTwcf6vprhjGEy6PNSE99PevVOGelrL1GhVk/ush5iwI8GDvsoRRF8YiIxKMy5xuu8IY/odF8y3xH2dFgHWfsQJC//NMvc6/7tXMeHdX4XWedk67ugaBqM1NkhhBUmGb4tF0HzuqUqn4NPIBJZiQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=intel.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hesYsjRcJDr0sDWp2Zlanbd+B0YVGF12dJ+EChCSS3c=; b=QwSAdJhlBVn/WJ3BkSQ0LauQzwF+WbNqqWzOoJHaboG+zIx14nKDSHc8lZzuNdrPUIdxLJ7aUXIQDTfi6E8Fg+YWakzPrKMBwspuXLbOZOyaMbEoBWcoh7Tcf6vUbvBCC9rDgOkUhdU46qtte5rlUkQ5l/QgMDtYDZaRC4EHRlA= Received: from BN9PR03CA0542.namprd03.prod.outlook.com (2603:10b6:408:138::7) by SA1PR12MB6946.namprd12.prod.outlook.com (2603:10b6:806:24d::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Fri, 4 Sep 2026 18:06:40 +0000 Received: from BN7PEPF0000009E.namprd04.prod.outlook.com (2603:10b6:408:138:cafe::ad) by BN9PR03CA0542.outlook.office365.com (2603:10b6:408:138::7) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.12 via Frontend Transport; Fri, 4 Sep 2026 18:06:39 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Received: from satlexmb07.amd.com (165.204.84.17) by BN7PEPF0000009E.mail.protection.outlook.com (10.167.248.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.8 via Frontend Transport; Fri, 4 Sep 2026 18:06:39 +0000 Received: from bmoger-ubuntu.amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Fri, 4 Sep 2026 13:06:39 -0500 From: Babu Moger To: , , , CC: , , , , , , , , , , , , Subject: [PATCH v2 3/3] x86/resctrl: Keep mbm_assign_mode in default mode at boot Date: Fri, 4 Sep 2026 13:06:12 -0500 Message-ID: <176d53626058ae97c4003f77ff47371628da9f1f.1788545152.git.babu.moger@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN7PEPF0000009E:EE_|SA1PR12MB6946:EE_ X-MS-Office365-Filtering-Correlation-Id: e919b443-f1ff-4f19-7786-08df0aaf44cc X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|36860700016|23010399003|376014|1800799024|7416014|10067099003|6133799003|3023799007|18002099003|22082099003|11063799006|56012099006|5023799004|13003099007; X-Microsoft-Antispam-Message-Info: hKmhCqbADfl9m99xhgNl05gFxR2SPEmCM7/fSM2AIScMEmPwdvXPJMOfsAA14n21atPJAcTMXm8njvCPkoqLNZBpnqmQdHLq4S8xWvJL4Wpi+2HEaCX3AlZoioCp2rcnB/CL6xRd/qSNejp8Lf134pzEbjTZg06pHHd3AQwh1P+DGWxX1lQAgpkMNk+Cf5zKQRsKMct41KTC5/19f8DP7bxJs1HKpQqcQBI9v8QWojnI4/ee0AHF9zZ4A3/GZoyQLqxsegN8ojcRvnLPuKA9xsjql6jBUPDCR7PzKwhyZ29bE52w8zMwV9qQ36srtA33zHXSmgw4Q8JTAIiB7ugcjOHTVsFgPqik9nAUkPMiYbyLlpi8TwEdHvbSsSfiT/6U63nYE2pw2YzbXpsRBJG4c2RABr0jl7/kStk58K4vumgZCFhXmQFYFKa3nzWjsVrIu85vkaj4pz7j7T/EH4ftnOn+TtDCSYtSmUuSrpuM3t2P0z2cvYgBZuPh8ADUnGBl+xEHFk6W1BFkxorYp4/WuH+33r6Hdr3KbDsUe2iW3CNUxxku0skuY8sAqNaQGv3l3fB/zDaT10f2y8fPrKrIQGHmH1Sbepk8BtEoBEsWHjFYivsVT9GyGfZK3qveQ4nIOh1NEz3EhjlbZa0d2ZG+l1oNpW9kHxy0oE1dK/uLwGILv1OWGHgdFdkpTL3W7jHC6VSDkiOqYGwMcCThRc5rSw== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700016)(23010399003)(376014)(1800799024)(7416014)(10067099003)(6133799003)(3023799007)(18002099003)(22082099003)(11063799006)(56012099006)(5023799004)(13003099007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: PDLX9rUxbUy+fhvFCv+T2ARw/zQdZSbqClPyW/S8bh92nKvdgxp3Azfu6iYDJwW3MtRf662efev0sPbv6ZSX869P1ND0q8jW0zKcduXdZhvthpUWl4dVJndI8qAQW9bSGC6u0urUbQQSs2Moz+kbL8fYXSi+uEPkUMX0ZwvHgrOkicpJ2rRIYouNKZ0ZYUPEoQnUmGUg+BI+hMXexjBWbgTDt9frQjjy7dE/WDWZNICrF8GPK93mfnCstDinW3OuqEtFR2Z3oKa/CaMOTcnnLVPGeqJ1S2r4FBHCxg7xB+kE+hktBXyANP1omPh2FiUjyRDD2AvWenEAvVPh3jXvw05PhN5Pr/11n3HUp/enWKv2g/aoPQi3q+zBHMMRakukgvgTyd9U9L1euEK/ednyDaEQhiGi/+dAkytYXeiDQ0UEIIPE0PTbUwN4pip7Wk3J X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2026 18:06:39.9248 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e919b443-f1ff-4f19-7786-08df0aaf44cc X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN7PEPF0000009E.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB6946 Content-Type: text/plain; charset="utf-8" ABMC ("mbm_event" mode) allows explicit assignment of hardware MBM counters to RMID/event pairs. It is intended for deployments that need to manage counter assignment on platforms where the number of monitoring groups exceeds the available hardware counters. Because hardware MBM counters are scarce, mbm_event mode is best suited for snapshot-and-rotation workflows that monitor a subset of groups at a time. Commit 0f1576e43adc ("x86/resctrl: Configure mbm_event mode if supported") enabled ABMC automatically during initialization. This causes problems on systems with limited MBM counters and breaks existing userspace that assumes the historical default mode, including the pqos tool from intel-cmt-cat [1]. For example, pqos mounts resctrl and creates 16 or more monitoring groups, using two counters per group (mbm_local_bytes and mbm_total_bytes). On platforms that provide 32 MBM counters per domain, this consumes the entire counter pool. Additional groups cannot be assigned counters and pqos reports zero bandwidth for them. Leave mbm_assign_mode in "default" mode during initialization. Default mode can support more monitoring groups (up to 64) than mbm_event mode, which is typically limited to 16 groups because of hardware counter availability. Common deployments with a modest number of monitoring groups continue to receive accurate bandwidth measurements. Users that require ABMC functionality can enable it explicitly: echo mbm_event > /sys/fs/resctrl/info/L3_MON/mbm_assign_mode Note that default mode has a long-standing limitation when the number of monitoring groups exceeds the available counter pool. After hardware counter reallocation, reads may return "Unavailable" or misleading values. Users that need stable measurements across a large number of monitoring groups should use mbm_event mode and rotate assignments as needed. Update Documentation/filesystems/resctrl.rst to reflect the default boot behavior, document the limitations of default mode, and adjust mbm_assign_mode examples accordingly. Signed-off-by: Babu Moger Link: https://github.com/intel/intel-cmt-cat/issues/311 # [1] --- v2: Added documentation describing the known issue with the default mode. Will add cc to stable once we have all the things in order. Let me know if I missed anything. v1: https://lore.kernel.org/lkml/8cb66e18e32e4087a9712c1e68ee6da614efe244.178= 4322818.git.babu.moger@amd.com/ --- Documentation/filesystems/resctrl.rst | 79 +++++++++++++++++---------- arch/x86/kernel/cpu/resctrl/monitor.c | 1 - 2 files changed, 49 insertions(+), 31 deletions(-) diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesyst= ems/resctrl.rst index 79feeb1dc296..a43ed3c89a93 100644 --- a/Documentation/filesystems/resctrl.rst +++ b/Documentation/filesystems/resctrl.rst @@ -355,8 +355,8 @@ with the following files: :: =20 # cat /sys/fs/resctrl/info/L3_MON/mbm_assign_mode - [mbm_event] - default + [default] + mbm_event =20 "mbm_event": =20 @@ -377,20 +377,30 @@ with the following files: will return 'Unassigned' when read until the user assigns one using "mbm_L3_assignments". =20 - The mode is beneficial for AMD platforms that support more CTRL_MON - and MON groups than available hardware counters. By default, this - feature is enabled on AMD platforms with the ABMC (Assignable Bandwidth - Monitoring Counters) capability, ensuring counters remain assigned even - when the corresponding RMID is not actively used by any processor. + The mode is beneficial for AMD platforms that support more CTRL_MON and M= ON + groups than available hardware counters. The mbm_event mode ensures count= ers + remain assigned even when the corresponding RMID is not actively monitore= d. =20 "default": =20 In default mode, resctrl assumes there is a hardware counter for each - event within every CTRL_MON and MON group. On AMD platforms, it is - recommended to use the mbm_event mode, if supported, to prevent reset of = MBM - events between reads resulting from hardware re-allocating counters. This= can - result in misleading values or display "Unavailable" if no counter is ass= igned - to the event. + event within every CTRL_MON and MON group. This mode is enabled by defaul= t. + + Default mode has a long-standing limitation on AMD platforms that support + more CTRL_MON and MON groups than hardware counters. Hardware dynamically + shares a smaller pool of counters among RMIDs. The size of that pool is + not enumerated to software (unlike "num_mbm_cntrs" in mbm_event mode), and + "num_rmids" may be much larger. On current AMD platforms this pool can + provide more counters than mbm_event mode (for example 64, versus 32 ABMC + counters), so more groups can be monitored accurately than with mbm_event. + Typical usage with fewer groups keeps a counter attached and readings + remain accurate. Creating more groups than that pool (for example 64 or + more) can cause hardware to re-allocate counters + between reads. Bandwidth values may then be misleading, or reads may retu= rn + "Unavailable" if no counter is allocated to the event. There is no + user-visible indication when this begins. Users who need stable readings + for many groups should switch to mbm_event mode, if supported, and assign + counters to the groups of interest (rotating assignments as needed). =20 * To enable "mbm_event" counter assignment mode: :: @@ -474,8 +484,8 @@ with the following files: =20 Determines if a counter will automatically be assigned to an RMID, MBM ev= ent pair when its associated monitor group is created via mkdir. Enabled by d= efault - on boot, also when switched from "default" mode to "mbm_event" counter as= signment - mode. Users can disable this capability by writing to the interface. + when switched to "mbm_event" counter assignment mode. Users can disable t= his + capability by writing to the interface. =20 "0": Auto assignment is disabled. @@ -1791,32 +1801,41 @@ a. Check if MBM counter assignment mode is supporte= d. =20 # mount -t resctrl resctrl /sys/fs/resctrl/ =20 + # cat /sys/fs/resctrl/info/L3_MON/mbm_assign_mode + [default] + mbm_event + +The "mbm_event" and "default" modes are supported. The "default" mode +is enabled by default. + +b. Enable "mbm_event" counter assignment mode. +:: + + # echo "mbm_event" > /sys/fs/resctrl/info/L3_MON/mbm_assign_mode # cat /sys/fs/resctrl/info/L3_MON/mbm_assign_mode [mbm_event] default =20 -The "mbm_event" mode is detected and enabled. - -b. Check how many assignable counters are supported. +c. Check how many assignable counters are supported. :: =20 # cat /sys/fs/resctrl/info/L3_MON/num_mbm_cntrs 0=3D32;1=3D32 =20 -c. Check how many assignable counters are available for assignment in each= domain. +d. Check how many assignable counters are available for assignment in each= domain. :: =20 # cat /sys/fs/resctrl/info/L3_MON/available_mbm_cntrs 0=3D30;1=3D30 =20 -d. To list the default group's assign states. +e. To list the default group's assign states. :: =20 # cat /sys/fs/resctrl/mbm_L3_assignments mbm_total_bytes:0=3De;1=3De mbm_local_bytes:0=3De;1=3De =20 -e. To unassign the counter associated with the mbm_total_bytes event on d= omain 0. +f. To unassign the counter associated with the mbm_total_bytes event on d= omain 0. :: =20 # echo "mbm_total_bytes:0=3D_" > /sys/fs/resctrl/mbm_L3_assignments @@ -1824,7 +1843,7 @@ e. To unassign the counter associated with the mbm_t= otal_bytes event on domain mbm_total_bytes:0=3D_;1=3De mbm_local_bytes:0=3De;1=3De =20 -f. To unassign the counter associated with the mbm_total_bytes event on al= l domains. +g. To unassign the counter associated with the mbm_total_bytes event on al= l domains. :: =20 # echo "mbm_total_bytes:*=3D_" > /sys/fs/resctrl/mbm_L3_assignments @@ -1832,7 +1851,7 @@ f. To unassign the counter associated with the mbm_to= tal_bytes event on all doma mbm_total_bytes:0=3D_;1=3D_ mbm_local_bytes:0=3De;1=3De =20 -g. To assign a counter associated with the mbm_total_bytes event on all do= mains in +h. To assign a counter associated with the mbm_total_bytes event on all do= mains in exclusive mode. :: =20 @@ -1841,7 +1860,7 @@ exclusive mode. mbm_total_bytes:0=3De;1=3De mbm_local_bytes:0=3De;1=3De =20 -h. Read the events mbm_total_bytes and mbm_local_bytes of the default grou= p. There is +i. Read the events mbm_total_bytes and mbm_local_bytes of the default grou= p. There is no change in reading the events with the assignment. :: =20 @@ -1854,7 +1873,7 @@ no change in reading the events with the assignment. # cat /sys/fs/resctrl/mon_data/mon_L3_01/mbm_local_bytes 121212144 =20 -i. Check the event configurations. +j. Check the event configurations. :: =20 # cat /sys/fs/resctrl/info/L3_MON/event_configs/mbm_total_bytes/event_fi= lter @@ -1864,7 +1883,7 @@ i. Check the event configurations. # cat /sys/fs/resctrl/info/L3_MON/event_configs/mbm_local_bytes/event_fi= lter local_reads,local_non_temporal_writes,local_reads_slow_memory =20 -j. Change the event configuration for mbm_local_bytes. +k. Change the event configuration for mbm_local_bytes. :: =20 # echo "local_reads, local_non_temporal_writes, local_reads_slow_memory,= remote_reads" > @@ -1873,7 +1892,7 @@ j. Change the event configuration for mbm_local_bytes. # cat /sys/fs/resctrl/info/L3_MON/event_configs/mbm_local_bytes/event_fi= lter local_reads,local_non_temporal_writes,local_reads_slow_memory,remote_rea= ds =20 -k. Now read the local events again. The first read may come back with "Una= vailable" +l. Now read the local events again. The first read may come back with "Una= vailable" status. The subsequent read of mbm_local_bytes will display the current va= lue. :: =20 @@ -1886,9 +1905,9 @@ status. The subsequent read of mbm_local_bytes will d= isplay the current value. # cat /sys/fs/resctrl/mon_data/mon_L3_01/mbm_local_bytes 1566565 =20 -l. Users have the option to go back to 'default' mbm_assign_mode if requir= ed. This can be -done using the following command. Note that switching the mbm_assign_mode = may reset all -the MBM counters (and thus all MBM events) of all the resctrl groups. +m. Users have the option to switch back to 'default' mbm_assign_mode if re= quired. This +can be done using the following command. Note that switching the mbm_assig= n_mode may +reset all the MBM counters (and thus all MBM events) of all the resctrl gr= oups. :: =20 # echo "default" > /sys/fs/resctrl/info/L3_MON/mbm_assign_mode @@ -1896,7 +1915,7 @@ the MBM counters (and thus all MBM events) of all the= resctrl groups. mbm_event [default] =20 -m. Unmount the resctrl filesystem. +n. Unmount the resctrl filesystem. :: =20 # umount /sys/fs/resctrl/ diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c b/arch/x86/kernel/cpu/re= sctrl/monitor.c index 3838e0a13d36..8a0d6086518b 100644 --- a/arch/x86/kernel/cpu/resctrl/monitor.c +++ b/arch/x86/kernel/cpu/resctrl/monitor.c @@ -471,7 +471,6 @@ int __init rdt_get_l3_mon_config(struct rdt_resource *r) r->mon.mbm_cntr_configurable =3D true; cpuid_count(0x80000020, 5, &eax, &ebx, &ecx, &edx); r->mon.num_mbm_cntrs =3D (ebx & GENMASK(15, 0)) + 1; - hw_res->mbm_cntr_assign_enabled =3D true; } =20 r->mon_capable =3D true; --=20 2.43.0