linux-kernel - Re: [PATCH V2 1/1] x86/resctrl: Remove unappropriate references to cacheinfo in the resctrl subsystem.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3ab80f7a-d4fd-4417-a728-ea2dd7cf740a@linux.alibaba.com>
Date: Fri, 30 May 2025 09:42:19 +0800
From: qinyuntan <qinyuntan@...ux.alibaba.com>
To: "Luck, Tony" <tony.luck@...el.com>
Cc: "H . Peter Anvin" <hpa@...or.com>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "x86@...nel.org" <x86@...nel.org>,
 "Chatre, Reinette" <reinette.chatre@...el.com>
Subject: Re: [PATCH V2 1/1] x86/resctrl: Remove unappropriate references to
 cacheinfo in the resctrl subsystem.

Hi Tony Luck,

Thank you very much for your review and testing of my patch. Reinette 
has provided some suggestions based on the commit logs. After I modify 
the commit log, I will send you the third version of the patch.

Best regards,
Qinyun Tan

On 5/30/25 2:14 AM, Luck, Tony wrote:
>> To resolve these issues:
>>
>> 1. Replace direct cacheinfo references in struct rdt_mon_domain and struct
>> rmid_read with the cacheinfo ID (a unique identifier for the L3 cache).
>>
>> 2. The hdr.cpu_mask maintained by resctrl constitutes a subset of
>> shared_cpu_map. When reading top-level events, we dynamically select a CPU
>> from hdr.cpu_mask and utilize its corresponding shared_cpu_map for resctrl
>> to determine valid CPUs for reading RMID counter via the MSR interface.
>>
>> Fixes: 328ea68874642 ("x86/resctrl: Prepare for new Sub-NUMA Cluster (SNC) monitor files")
>> Signed-off-by: Qinyun Tan <qinyuntan@...ux.alibaba.com>
> 
> Took this patch on a test run on a 2 socket Granite Rapids system configured
> in SNC 3 mode.
> 
> While monitoring total memory bandwidth I took the first CPU on NUMA
> nodes {1..5} offline. Monitoring kept working. Brought those back online.
> Still OK. Took all CPUs on NUMA node 4 offline. Still good. Brought those
> CPUs back online. Still good.
> 
> Tested-by: Tony Luck <tony.luck@...el.com>
> 
> -Tony