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
