[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <6t37aaepgw3r4db4t5usfc2zz3mv3ugzcreleig5md7wlyjnzc@5eie6g7m3hhi>
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
Powered by blists - more mailing lists