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 v4 2/2] selftests/resctrl: Adjust SNC support messages
Date: Tue, 17 Sep 2024 08:32:11 -0700 [thread overview]
Message-ID: <7ccac5b3-cfba-4f31-804b-45da60b0c08f@intel.com> (raw)
In-Reply-To: <zrcau5572lcuahcbntk6bcqh4dcin3jkcjeesvltz7zutriu3c@5v6puvyzayqc>
Hi Maciej,
On 8/27/24 1:15 AM, Maciej Wieczor-Retman wrote:
> On 2024-08-12 at 16:40:10 -0700, Reinette Chatre wrote:
>> On 7/12/24 2:04 AM, Maciej Wieczor-Retman wrote:
>>> +
>>> + if ((get_vendor() == ARCH_INTEL) && snc_unreliable) {
>>> + ksft_print_msg("Sub-NUMA Clustering could not be detected properly (see earlier messages for details).\n");
>>> + ksft_print_msg("Intel CAT may be inaccurate.\n");
>>> + }
>>
>> This is still relevant but unclear why previous message checked "ret" but above does not.
>
> The above check tries to explain why a failure happened.
>
> This check is a reminder about a false positive - the test passes but
> "snc_unreliable" was set. I guess we could make this check to test "!ret"?
Thinking about this more ... if the test results cannot be trusted at all (whether tests pass or
fail) when snc_reliable is true then it seems more appropriate to just skip these tests when
SNC detection is unreliable.
>
>>
>>> +
>>> return ret;
>>> }
>>> diff --git a/tools/testing/selftests/resctrl/cmt_test.c b/tools/testing/selftests/resctrl/cmt_test.c
>>> index 0c045080d808..471e134face0 100644
>>> --- a/tools/testing/selftests/resctrl/cmt_test.c
>>> +++ b/tools/testing/selftests/resctrl/cmt_test.c
>>> @@ -175,8 +175,14 @@ static int cmt_run_test(const struct resctrl_test *test, const struct user_param
>>> goto out;
>>> ret = check_results(¶m, span, n);
>>> - if (ret && (get_vendor() == ARCH_INTEL))
>>> - ksft_print_msg("Intel CMT may be inaccurate when Sub-NUMA Clustering is enabled. Check BIOS configuration.\n");
>>> + if (ret && (get_vendor() == ARCH_INTEL) && !snc_kernel_support())
>>> + ksft_print_msg("Kernel doesn't support Sub-NUMA Clustering but it is enabled on the system.\n");
>>> +
>>> + if ((get_vendor() == ARCH_INTEL) && snc_unreliable) {
>>> + ksft_print_msg("Sub-NUMA Clustering could not be detected properly (see earlier messages for details).\n");
>>> + ksft_print_msg("Intel CMT may be inaccurate.\n");
>>> + }
>>> +
>>
>> CMT may be inaccurate in both scenarios (no kernel support or unreliable detection). Why only
>> check "ret" in case there is no kernel support?
>
> I guess the same thing from above can apply here? Test "!ret"? Perhaps then make
> this check into "else if ()" instead of just "if" since they will be exclusive?
>
>>
>>> out:
>>> free(span_str);
>>> diff --git a/tools/testing/selftests/resctrl/mba_test.c b/tools/testing/selftests/resctrl/mba_test.c
>>> index ab8496a4925b..a805c14fe04b 100644
>>> --- a/tools/testing/selftests/resctrl/mba_test.c
>>> +++ b/tools/testing/selftests/resctrl/mba_test.c
>>> @@ -179,6 +179,13 @@ static int mba_run_test(const struct resctrl_test *test, const struct user_param
>>> return ret;
>>> ret = check_results();
>>> + if (ret && (get_vendor() == ARCH_INTEL) && !snc_kernel_support())
>>> + ksft_print_msg("Kernel doesn't support Sub-NUMA Clustering but it is enabled on the system.\n");
>>> +
>>> + if ((get_vendor() == ARCH_INTEL) && snc_unreliable) {
>>> + ksft_print_msg("Sub-NUMA Clustering could not be detected properly (see earlier messages for details).\n");
>>> + ksft_print_msg("Intel MBA may be inaccurate.\n");
>>> + }
>>
>> As I understand there is no change to MBA when SNC is enabled. These additions thus seem unnecessary.
>
> I just rechecked by installing 6.9 kernel (no SNC kernel support) and using this
> series selftest. MBA seems to fail in these conditions. I think it is because
> MBA pulls values from resctrl and from iMC and then compares them. My guess is
> that iMC works on the halved cache while resctrl (without new SNC support) uses
> the whole cache. Here is the log from the MBA test I did:
Apologies, yes, while MBA is not impacted by SNC the MBA selftest relies on
MBM that is impacted by SNC.
Reinette
next prev parent reply other threads:[~2024-09-17 15:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-12 9:03 [PATCH v4 0/2] selftests/resctrl: SNC kernel support discovery Maciej Wieczor-Retman
2024-07-12 9:04 ` [PATCH v4 1/2] selftests/resctrl: Adjust effective L3 cache size with SNC enabled Maciej Wieczor-Retman
2024-08-12 23:40 ` Reinette Chatre
2024-08-27 6:45 ` Maciej Wieczor-Retman
2024-07-12 9:04 ` [PATCH v4 2/2] selftests/resctrl: Adjust SNC support messages Maciej Wieczor-Retman
2024-08-12 23:40 ` Reinette Chatre
2024-08-27 8:15 ` Maciej Wieczor-Retman
2024-09-17 15:32 ` Reinette Chatre [this message]
2024-09-19 14:42 ` 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=7ccac5b3-cfba-4f31-804b-45da60b0c08f@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox