linux-kernel - Re: [morse:mpam/move_to_fs/v7_bare] [x86/resctrl] 0021800a46: will-it-scale.per_process

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] [day] [month] [year] [list]

Message-ID: <47c6a2cb-76a6-4e7e-b6e8-3896f78f2f65@intel.com>
Date: Mon, 10 Mar 2025 19:30:40 -0700
From: Reinette Chatre <reinette.chatre@...el.com>
To: Oliver Sang <oliver.sang@...el.com>
CC: James Morse <james.morse@....com>, <oe-lkp@...ts.linux.dev>,
	<lkp@...el.com>, Shaopeng Tan <tan.shaopeng@...fujitsu.com>, Tony Luck
	<tony.luck@...el.com>, <linux-kernel@...r.kernel.org>
Subject: Re: [morse:mpam/move_to_fs/v7_bare] [x86/resctrl] 0021800a46:
 will-it-scale.per_process_ops 18.4% improvement

Hi Oliver,

On 3/10/25 6:21 PM, Oliver Sang wrote:
> On Mon, Mar 10, 2025 at 02:17:51PM -0700, Reinette Chatre wrote:
>> On 3/10/25 7:06 AM, kernel test robot wrote:
>>>
>>>
>>> Hello,
>>>
>>> kernel test robot noticed a 18.4% improvement of will-it-scale.per_process_ops on:
>>>
>>>
>>> commit: 0021800a465d495a536265c52f8a031da43948ed ("x86/resctrl: Use schema type to determine the schema format string")
>>> https://git.kernel.org/cgit/linux/kernel/git/morse/linux.git mpam/move_to_fs/v7_bare
>>>
>>> testcase: will-it-scale
>>> config: x86_64-rhel-9.4
>>> compiler: gcc-12
>>> test machine: 224 threads 2 sockets Intel(R) Xeon(R) Platinum 8480CTDX (Sapphire Rapids) with 512G memory
>>> parameters:
>>>
>>> 	nr_task: 100%
>>> 	mode: process
>>> 	test: signal1
>>> 	cpufreq_governor: performance
>>>
>>>
>>> In addition to that, the commit also has significant impact on the following tests:
>>>
>>> +------------------+---------------------------------------------------------------------------------------------+
>>> | testcase: change | stress-ng: stress-ng.usersyscall.ops_per_sec 18.0% improvement                              |
>>> | test machine     | 224 threads 2 sockets Intel(R) Xeon(R) Platinum 8480CTDX (Sapphire Rapids) with 512G memory |
>>> | test parameters  | cpufreq_governor=performance                                                                |
>>> |                  | nr_threads=100%                                                                             |
>>> |                  | test=usersyscall                                                                            |
>>> |                  | testtime=60s                                                                                |
>>> +------------------+---------------------------------------------------------------------------------------------+
>>>
>>>
>>>
>>>
>>> Details are as below:
>>> -------------------------------------------------------------------------------------------------->
>>>
>>>
>>> The kernel config and materials to reproduce are available at:
>>> https://download.01.org/0day-ci/archive/20250310/202503102156.d70c4800-lkp@intel.com
>>>
>>> =========================================================================================
>>> compiler/cpufreq_governor/kconfig/mode/nr_task/rootfs/tbox_group/test/testcase:
>>>   gcc-12/performance/x86_64-rhel-9.4/process/100%/debian-12-x86_64-20240206.cgz/lkp-spr-2sp4/signal1/will-it-scale
>>>
>>> commit: 
>>>   a13ae432a6 ("x86/resctrl: Use schema type to determine how to parse schema values")
>>>   0021800a46 ("x86/resctrl: Use schema type to determine the schema format string")
>>>
>>
>> It is surprising to me that these commits make a difference in these workloads. I searched around for resctrl in
>> https://github.com/intel/lkp-tests but is seems as though it runs the resctrl selftests only and do not
>> use resctrl as part of any tests reported here. From what I understand, by not even mounting resctrl, these tests
>> (a) do not exercise these code paths, and (b) do not use resctrl to control resources allocated for these workloads. 
> 
> thanks a lot for education! this could be an alignment issue.
> 
> since we found similar performanance impacts on different cases, so made out
> the report FYI. seems a false positive. sorry about cost your time to check.
> 

I think it is important to understand this behavior, but unfortunately I cannot explain it by
considering the patches identified. resctrl can only be built into the kernel so indeed may impact
alignment.

Reinette