From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794585592; b=shUqgvCvY2+fGo2OVcdGm1+z51f9BluoYbpBMZizSogBAdtn+GZ03GmWZ2pdccB6yebK rPpVHHlzjdgyQYfpG6JfaPlUWioDH2nkZ7rJ3/7PuwsbPulLBehKWO52clinmSkccwhtt tDcetT1yJ5eHnAN/NJ+czJEKHXBpLdajsQIpkTbkAUKHpV+eaFImdSWh9f0vYi7632JnH sRtp5UNwTg1SDd1JbIEK4EC3wJF5d4iblyPfp0LvMeVBvYJw/8/lZddIX2nFB4vkKjZOO MyL4NbCZ9q/RUziToe42XRv+VHqQbe/wtnKf2SKu7/k05LLb3NZm0qICuq+WpRtaamg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794585592; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:User-Agent:X-stable:X-Patchwork-Hint: MIME-Version:Content-Type:Content-Transfer-Encoding; bh=PZ+iWMQVbwnA3jqpl48NrY3SvQkeg71FxsxO4e6TrNQ=; b=kXpQEE28eKgqGHzQ2H/cW6b9FzdCNTh4MtfX+gk64KBBWa/x2DFaqjbUVEjmE4gpIr8k VKLZqDOsdac11sSJsaSTSDfPiHEoOfY/UH8LdczpKOEUz+6bXptFUph/gx0vEm83+t58V lnaOzMR7vThW/mVYs+raqzopXPbzrCmGemgcB96+kmOBnYPB8cWDmROyfV3FQwxEHAXqh 17HTfl/qL7wkDnpdnZSbfQUk3TVslvwF5RrYbkX2yk61SYWoxsBxHiG4+sRMNe2nL8T+C lMh1GTOuweuBOCyXfqDK2htdCVDyWuc0p3VU6EqA+yrcLYfUxk/seIqHY2+5W4UCfgw== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=vTpsEhIU; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ED195606FFEC; Fri, 13 Nov 2026 15:59:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=vTpsEhIU Received: by smtp.kernel.org (Postfix) with ESMTPSA id 51E1D1F000C4; Fri, 13 Nov 2026 15:59:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1794585591; bh=PZ+iWMQVbwnA3jqpl48NrY3SvQkeg71FxsxO4e6TrNQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=vTpsEhIU88+zEODH8TN6XxfZMY/TTKnY6r3TNAQcKRqPurTif3yi0NsXVwaV3pIFf cVflwpcweMgaLe0DOIQkrKVdeF40jSfqIbel1tWYi3adXx4fg08dh6fMq6UUW1wkQs h7NEC6c/8LfNPhe9epHmzKluF0Ns/2BcRppFJJ2w= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Babu Moger , "Borislav Petkov (AMD)" , Sasha Levin Subject: [PATCH 7.3 220/507] x86,fs/resctrl: Keep mbm_assign_mode in default mode at boot Date: Fri, 13 Nov 2026 10:48:44 -0500 Message-ID: <20261113153801.948752414@linuxfoundation.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261113153753.358973689@linuxfoundation.org> References: <20261113153753.358973689@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore X-Mailing-List: stable@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 7.3-stable review patch. If anyone has any objections, please let me know. ------------------ From: Babu Moger [ Upstream commit 7782a6a8dfc05f5622fdf616e5cf3df7d16eaef5 ] The mbm_event mode assigns 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. Hardware counters are scarce on these platforms, so mbm_event mode suits workflows that monitor a subset of groups at a time and rotate assignments as needed. x86 resctrl enables the mbm_event mode by default on hardware that supports it. This breaks the pqos tool¹, which assumes the historical default mode. It creates 16 or more monitoring groups and uses two counters per group. On a platform with 32 counters per domain, that exhausts the mbm_event counters pool, causing additional groups to read "Unassigned". pqos interprets a non-numeric event read as zero bandwidth and reports 0 MB/s for those groups: $ sudo pqos -m all:0-4 CORE IPC MISSES LLC[KB] MBL[MB/s] MBR[MB/s] 0 0.69 16k 192.0 0.0 0.0 1 0.40 3k 0.0 0.0 0.0 2 0.44 1k 64.0 0.0 0.0 3 0.39 1k 64.0 0.0 0.0 4 0.43 1k 0.0 0.0 0.0 Leave mbm_assign_mode in default mode during initialization as decided in the thread at the Link tag. Default mode uses one counter per monitoring group. On existing AMD platforms, the default active counters pool is 64 and may be larger on newer hardware. The active counters pool is the number of counters that the hardware can actively track in default mode. Deployments within the active counters pool receive accurate bandwidth measurements in the default mode. Users can create more monitoring groups (for example, 4096 on current hardware) than there are active counters in the pool. Beyond that pool, readings may be misleading or report as "Unavailable", with no user-visible indication. Default mode is still limited once the number of monitoring groups exceeds that active counters pool. After hardware re-allocates a counter, a read may return "Unavailable". pqos still treats "Unavailable" as zero. Successive reads can be a count, "Unavailable", then another count. pqos treats those jumps as wraparound and can report an inconsistent rate: $ sudo pqos -m all:0-4 CORE IPC MISSES LLC[KB] MBL[MB/s] MBR[MB/s] 0 0.76 60k 32.0 0.0 0.0 1 0.45 1k 32.0 0.0 0.0 2 1.57 107k 64.0 0.0 17592186044184.9 3 1.62 276k 4928.0 3.2 0.5 Users that need stable measurements beyond the active counters pool should use mbm_event mode and rotate assignments as needed. Enable it with: # echo mbm_event > /sys/fs/resctrl/info/L3_MON/mbm_assign_mode ¹https://github.com/intel/intel-cmt-cat [ bp: Massage commit message. ] Fixes: 0f1576e43adc ("x86/resctrl: Configure mbm_event mode if supported") Closes: https://github.com/intel/intel-cmt-cat/issues/311 Signed-off-by: Babu Moger Signed-off-by: Borislav Petkov (AMD) Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20260804191608.GDanI6eK2Q07w6pNcb@fat_crate.local Signed-off-by: Sasha Levin --- Documentation/filesystems/resctrl.rst | 87 ++++++++++++++++----------- arch/x86/kernel/cpu/resctrl/monitor.c | 1 - 2 files changed, 51 insertions(+), 37 deletions(-) diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst index e4b66af55ffba..6b641c3cee644 100644 --- a/Documentation/filesystems/resctrl.rst +++ b/Documentation/filesystems/resctrl.rst @@ -351,12 +351,12 @@ with the following files: "mbm_assign_mode": The supported counter assignment modes. The enclosed brackets indicate which mode is enabled. The MBM events associated with counters may reset when "mbm_assign_mode" - is changed. + is changed. See architecture specific notes below. :: # cat /sys/fs/resctrl/info/L3_MON/mbm_assign_mode - [mbm_event] - default + [default] + mbm_event "mbm_event": @@ -374,20 +374,17 @@ with the following files: 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. - 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. + It is intended for deployments that need to manage counter assignment on + platforms where the number of monitoring groups exceeds the available + hardware counters. Hardware counters are scarce on these platforms, so + mbm_event mode suits workflows that monitor a subset of groups at a time and + rotate assignments as needed. The mbm_event mode ensures counters remain + assigned even when the corresponding RMID is not actively used. "default": 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 assigned - to the event. + event within every CTRL_MON and MON group. * To enable "mbm_event" counter assignment mode: :: @@ -399,6 +396,24 @@ with the following files: # echo "default" > /sys/fs/resctrl/info/L3_MON/mbm_assign_mode + In default mode on AMD platforms that support more CTRL_MON and MON groups + than hardware counters, hardware dynamically shares a smaller pool of + counters among RMIDs. One counter from this pool is used per monitoring + group and counts every MBM event of that group's RMID. The size of the pool + is not enumerated to software (unlike "num_mbm_cntrs"), and "num_rmids" may + be much larger. For example, 64 counters in this pool monitor 64 groups. + Newer hardware may provide a larger pool. + + On such platforms, while the number of monitoring groups does not exceed + that pool, a counter stays attached to each RMID and readings remain + accurate. Creating more groups than the pool can cause hardware to + re-allocate those counters between successive reads of an event. Bandwidth + values may then be misleading, or a read may return "Unavailable" if no + counter is allocated to the RMID. There is no user-visible indication when + this begins. Users who need stable readings beyond that pool should switch + to mbm_event mode, if supported, and assign counters to the groups of + interest (rotating assignments as needed). + "num_mbm_cntrs": The maximum number of counters (total of available and assigned counters) in each domain when the system supports mbm_event mode. @@ -1783,17 +1798,19 @@ View the llc occupancy snapshot:: Examples on working with mbm_assign_mode ======================================== -a. Check if MBM counter assignment mode is supported. +a. Check if MBM counter assignment mode is supported. Enable "mbm_event" +mode. Switching the mbm_assign_mode may reset all the MBM counters (and +thus all MBM events) of all the resctrl groups. :: - # mount -t resctrl resctrl /sys/fs/resctrl/ - + # cat /sys/fs/resctrl/info/L3_MON/mbm_assign_mode + [default] + mbm_event + # 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 -The "mbm_event" mode is detected and enabled. - b. Check how many assignable counters are supported. :: @@ -1804,36 +1821,39 @@ c. Check how many assignable counters are available for assignment in each domai :: # cat /sys/fs/resctrl/info/L3_MON/available_mbm_cntrs - 0=30;1=30 + 0=32;1=32 -d. To list the default group's assign states. +d. To list the default group's assign states. Counters are unassigned when the mode +is switched to "mbm_event". :: # cat /sys/fs/resctrl/mbm_L3_assignments - mbm_total_bytes:0=e;1=e - mbm_local_bytes:0=e;1=e + mbm_total_bytes:0=_;1=_ + mbm_local_bytes:0=_;1=_ -e. To unassign the counter associated with the mbm_total_bytes event on domain 0. +e. To assign the counter associated with the mbm_total_bytes event on domain 0 +in exclusive mode. :: - # echo "mbm_total_bytes:0=_" > /sys/fs/resctrl/mbm_L3_assignments + # echo "mbm_total_bytes:0=e" > /sys/fs/resctrl/mbm_L3_assignments # cat /sys/fs/resctrl/mbm_L3_assignments - mbm_total_bytes:0=_;1=e - mbm_local_bytes:0=e;1=e + mbm_total_bytes:0=e;1=_ + mbm_local_bytes:0=_;1=_ f. To unassign the counter associated with the mbm_total_bytes event on all domains. :: # echo "mbm_total_bytes:*=_" > /sys/fs/resctrl/mbm_L3_assignments - # cat /sys/fs/resctrl/mbm_L3_assignment + # cat /sys/fs/resctrl/mbm_L3_assignments mbm_total_bytes:0=_;1=_ - mbm_local_bytes:0=e;1=e + mbm_local_bytes:0=_;1=_ -g. To assign a counter associated with the mbm_total_bytes event on all domains in -exclusive mode. +g. To assign a counter associated with the mbm_total_bytes and mbm_local_bytes +events on all domains in exclusive mode. :: # echo "mbm_total_bytes:*=e" > /sys/fs/resctrl/mbm_L3_assignments + # echo "mbm_local_bytes:*=e" > /sys/fs/resctrl/mbm_L3_assignments # cat /sys/fs/resctrl/mbm_L3_assignments mbm_total_bytes:0=e;1=e mbm_local_bytes:0=e;1=e @@ -1890,13 +1910,8 @@ the MBM counters (and thus all MBM events) of all the resctrl groups. # echo "default" > /sys/fs/resctrl/info/L3_MON/mbm_assign_mode # cat /sys/fs/resctrl/info/L3_MON/mbm_assign_mode - mbm_event [default] - -m. Unmount the resctrl filesystem. -:: - - # umount /sys/fs/resctrl/ + mbm_event Intel RDT Errata ================ diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c b/arch/x86/kernel/cpu/resctrl/monitor.c index 5d0d3b18f9b82..a6a9090c4808c 100644 --- a/arch/x86/kernel/cpu/resctrl/monitor.c +++ b/arch/x86/kernel/cpu/resctrl/monitor.c @@ -472,7 +472,6 @@ int __init rdt_get_l3_mon_config(struct rdt_resource *r) cpuid_count(0x80000020, 5, &eax, &ebx, &ecx, &edx); /* cntr_id is 12 bits and can only encode 4096 counters. */ r->mon.num_mbm_cntrs = min((ebx & GENMASK(15, 0)) + 1, BIT(12)); - hw_res->mbm_cntr_assign_enabled = true; } r->mon_capable = true; -- 2.53.0