From: Reinette Chatre <reinette.chatre@intel.com>
To: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
Cc: <fenghua.yu@intel.com>, <shuah@kernel.org>,
<linux-kselftest@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<ilpo.jarvinen@linux.intel.com>, <tony.luck@intel.com>
Subject: Re: [PATCH v2 1/2] selftests/resctrl: Adjust effective L3 cache size with SNC enabled
Date: Thu, 27 Jun 2024 09:30:24 -0700 [thread overview]
Message-ID: <ded7afa5-7197-48e1-98bb-066b9df285fd@intel.com> (raw)
In-Reply-To: <ewkiaarsl4s4aofw2uykhup3eyutnzitlow3muzbaqqf4xp53g@6lgc5o2dkmor>
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.
> 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.
>
> 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.
>
> 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
Reinette
next prev parent reply other threads:[~2024-06-27 16:30 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-15 11:17 [PATCH v2 0/2] selftests/resctrl: SNC kernel support discovery Maciej Wieczor-Retman
2024-05-15 11:18 ` [PATCH v2 1/2] selftests/resctrl: Adjust effective L3 cache size with SNC enabled Maciej Wieczor-Retman
2024-05-15 16:48 ` Luck, Tony
2024-05-16 6:01 ` Maciej Wieczor-Retman
2024-05-30 23:07 ` Reinette Chatre
2024-05-30 23:46 ` Luck, Tony
2024-05-30 23:51 ` Reinette Chatre
2024-05-31 0:34 ` Luck, Tony
2024-05-31 16:17 ` Reinette Chatre
2024-06-25 11:04 ` Maciej Wieczor-Retman
2024-06-25 16:28 ` Reinette Chatre
2024-06-26 7:09 ` Maciej Wieczor-Retman
2024-06-26 16:46 ` Reinette Chatre
2024-06-27 9:50 ` Maciej Wieczor-Retman
2024-06-27 16:30 ` Reinette Chatre [this message]
2024-06-28 7:52 ` Maciej Wieczor-Retman
2024-05-15 11:18 ` [PATCH v2 2/2] selftests/resctrl: Adjust SNC support messages Maciej Wieczor-Retman
2024-05-30 23:07 ` Reinette Chatre
2024-05-31 6:39 ` Maciej Wieczor-Retman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ded7afa5-7197-48e1-98bb-066b9df285fd@intel.com \
--to=reinette.chatre@intel.com \
--cc=fenghua.yu@intel.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=maciej.wieczor-retman@intel.com \
--cc=shuah@kernel.org \
--cc=tony.luck@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.