[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <73cea732-3757-4aec-a39c-4f0e50f6fb70@intel.com>
Date: Wed, 17 Jan 2024 10:49:06 -0800
From: Reinette Chatre <reinette.chatre@...el.com>
To: Maciej Wieczór-Retman <maciej.wieczor-retman@...el.com>
CC: Fenghua Yu <fenghua.yu@...el.com>, Shuah Khan <shuah@...nel.org>,
<ilpo.jarvinen@...ux.intel.com>, <linux-kernel@...r.kernel.org>,
<linux-kselftest@...r.kernel.org>
Subject: Re: [PATCH v2 4/4] selftests/resctrl: Add non-contiguous CBMs CAT
test
Hi Maciej,
On 1/17/2024 12:26 AM, Maciej Wieczór-Retman wrote:
> On 2024-01-08 at 14:42:11 -0800, Reinette Chatre wrote:
>> On 12/12/2023 6:52 AM, Maciej Wieczor-Retman wrote:
>>> +
>>> + if (sparse_masks != ((ecx >> 3) & 1))
>>> + return -1;
>>
>> Can a message be displayed to support the debugging this test failure?
>
> Sure, that is a very good idea. I'll add ksft_perror() here.
I do not think ksft_perror() is appropriate since perror() is for
system error messages (something that sets errno). Perhaps just
ksft_print_msg().
>>> + bit_center = count_bits(full_cache_mask) / 2;
>>> + cont_mask = full_cache_mask >> bit_center;
>>> +
>>> + /* Contiguous mask write check. */
>>> + snprintf(schemata, sizeof(schemata), "%lx", cont_mask);
>>> + ret = write_schemata("", schemata, uparams->cpu, test->resource);
>>> + if (ret)
>>> + return ret;
>>
>> How will user know what failed? I am seeing this single test exercise a few scenarios
>> and it is not obvious to me if the issue will be clear if this test,
>> noncont_cat_run_test(), fails.
>
> write_schemata() either succeeds with '0' or errors out with a negative value. If
> the contiguous mask write fails, write_schemata should print out what was wrong
> and I believe that the test will report an error rather than failure.
Right. I am trying to understand whether the user will be able to decipher what failed
in case there is an error. Seems like in this case the user is expected to look at the
source code of the test to understand what the test was trying to do at the time it
encountered the failure. In this case user may be "lucky" that this test only has
one write_schemata() call _not_ followed by a ksft_print_msg() so user can use that
reasoning to figure out which write_schemata() failed to further dig what test was
trying to do.
Reinette
Powered by blists - more mailing lists