linux-kernel - Re: [PATCH v2 1/2] selftests/resctrl: Adjust effective L3 cache size with SNC enabled

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]

Date: Fri, 28 Jun 2024 09:52:18 +0200
From: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>
To: Reinette Chatre <reinette.chatre@...el.com>
CC: <fenghua.yu@...el.com>, <shuah@...nel.org>,
	<linux-kselftest@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<ilpo.jarvinen@...ux.intel.com>, <tony.luck@...el.com>
Subject: Re: [PATCH v2 1/2] selftests/resctrl: Adjust effective L3 cache size
 with SNC enabled

On 2024-06-27 at 09:30:24 -0700, Reinette Chatre wrote:
>Hi Maciej
>
>On 6/27/24 2:50 AM, Maciej Wieczor-Retman wrote:
>> 
>> Yeah, I've been thinking about what is the best way to display these for a
>> while. Maybe you're right that messages at the top will be lost. What about this
>> set of messages:
>> 
>> 1. First run of run_single_test()
>> 	1.1. For all tests:
>> 		- detected snc mode (if > 1)
>> 			- check if cpu/offline file is empty, set the global
>> 			  variable and print a message saying snc mode might be
>> 			  wrong
>
>When SNC detection is considered unreliable, everything else becomes unreliable also
>since kernel support for SNC is only visible (in future kernels) when SNC is enabled.
>I thus think that if it is found that SNC detection may be unreliable then the number
>of SNC nodes should be hardcoded to 1 and a default message about possible interference
>by SNC should be printed at all test failures.

Okay, that sounds good.

>
>> 2. At the end of tests
>> 	2.1. For CMT, CAT, MBM, MBA:
>> 		- test failed
>> 		- snc detection reports it's enabled
>> 		- kernel version doesn't support snc
>
>Sounds like the "all goes well" scenario when SNC support is reliably detected.

This was supposed to be the error message that was already there before - now
I'd just add the information about whether SNC was actually enabled.

>
>> 
>> 	2.2. Additional message for CMT, CAT (since the cache size is divided):
>> 		- test failed or succeeded
>> 		- snc detection reports the offline file is not empty
>> 		- kernel version supports snc
>
>I am not able to follow what happens in these scenarios.

And this I intended as an explanation to the example I mentioned earlier - the
test succeeds but the cache size was miscalculated due to offline cpus. But
after applying your suggestion above to just set the snc mode to 1 when SNC
detection is unreliable I guess this doesn't matter anymore.

>
>> 
>> The 1. message will be printed at the top since it's more informational (what is
>> the SNC mode?) and then 2. messages will deal with possible issues / failures
>> and will be nicely visible at the end. What do you think about this?
>
>It is not obvious to me what the messages may be but the times/locations when
>messages are printed sounds good to me.
>
>Thank you

Thanks for all the tips and great ideas, I hope to send the next version between
monday and wednesday after trying to trigger all possible corner cases.

>
>Reinette
>
>

-- 
Kind regards
Maciej Wieczór-Retman