mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Shaopeng Tan (Fujitsu)" <tan.shaopeng@fujitsu.com>
To: "'Reinette Chatre'" <reinette.chatre@intel.com>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	"Shuah Khan" <shuah@kernel.org>,
	"Shuah Khan" <skhan@linuxfoundation.org>,
	"linux-kselftest@vger.kernel.org"
	<linux-kselftest@vger.kernel.org>,
	"Maciej Wieczór-Retman" <maciej.wieczor-retman@intel.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: RE: [PATCH v2 1/6] selftests/resctrl: Extend signal handler coverage to unmount on receiving signal
Date: Thu, 5 Oct 2023 07:53:29 +0000	[thread overview]
Message-ID: <TYAPR01MB6330FD62ED8A752ECDA8AF948BCAA@TYAPR01MB6330.jpnprd01.prod.outlook.com> (raw)
In-Reply-To: <0033ee44-5383-4e69-b85d-ed88592bee94@intel.com>

Hello Reinette,

> On 9/28/2023 1:10 AM, Shaopeng Tan (Fujitsu) wrote:
> >> On 9/15/2023 8:44 AM, Ilpo Järvinen wrote:
> 
> ...
> 
> >>> +static void run_mbm_test(const char * const *benchmark_cmd, int
> >>> +cpu_no) {
> >>> +	int res;
> >>> +
> >>> +	ksft_print_msg("Starting MBM BW change ...\n");
> >>> +
> >>> +	if (test_prepare())
> >>> +		return;
> >>>
> >>
> >> I am not sure about this. With this exit the kselftest machinery is
> >> not aware of the test passing or failing. I wonder if there should
> >> not rather be a "goto" here that triggers ksft_test_result()? This
> >> needs some more thought though. First, with this change
> >> test_prepare() officially gains responsibility to determine if a
> >> failure is transient (just a single test
> >> fails) or permanent (no use trying any other tests if this fails).
> >> For the former it would then be up to the caller to call
> >> ksft_test_result() and for the latter
> >> test_prepare() will call ksft_exit_fail_msg().
> >> Second, that SNC warning may be an inconvenience with a new goto.
> >> Here it may be ok to print that message before the test failure?
> >
> > If a failure may be permanent, it may be best to detect it before running all
> tests, rather than in test_prepare().
> > Now some detections are completed before running all tests. For example:
> > 273         if (geteuid() != 0)
> > 274                 return ksft_exit_skip("Not running as root.
> Skipping...\n");
> > 275
> > 276         if (!check_resctrlfs_support())
> > 277                 return ksft_exit_skip("resctrl FS does not exist. Enable
> X86_CPU_RESCTRL config option.\n");
> > 278
> > 279         if (umount_resctrlfs())
> > 280                 return ksft_exit_skip("resctrl FS unmount failed.\n");
> >
> 
> You are correct that the tests should aim to detect as early as possible if no test
> has a chance of succeeding. This is covered in the checks you mention.
> The purpose of test_prepare()/test_cleanup() pair is to perform actions that
> should be done for every test. For example, resctrl is mounted before each test
> and unmounted after each test. Since these actions are required to be done for
> every test it cannot be a single call before all tests are run.
> 
> It may be possible to add a test_prepare() directly followed by a test_cleanup()
> before any test is run to be more explicit about early detection but that does not
> seem necessary considering the checks would be done anyway when the first
> test is run. Even when doing so it would not eliminate the need for
> test_prepare()/test_cleanup() to form part of every test run and needing to exit
> if, for example, a previous test triggered a fault preventing resctrl from being
> mounted.

Thanks for your explanation. I understand

Best regards,
Shaopeng TAN



  reply	other threads:[~2023-10-05 16:20 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-15 15:44 [PATCH v2 0/6] selftests/resctrl: Fixes to failing tests Ilpo Järvinen
2023-09-15 15:44 ` [PATCH v2 1/6] selftests/resctrl: Extend signal handler coverage to unmount on receiving signal Ilpo Järvinen
2023-09-26 21:38   ` Reinette Chatre
2023-09-28  8:10     ` Shaopeng Tan (Fujitsu)
2023-10-04 17:43       ` Reinette Chatre
2023-10-05  7:53         ` Shaopeng Tan (Fujitsu) [this message]
2023-09-28 12:47     ` Ilpo Järvinen
2023-09-28 17:09       ` Reinette Chatre
2023-09-15 15:44 ` [PATCH v2 2/6] selftests/resctrl: Remove duplicate feature check from CMT test Ilpo Järvinen
2023-09-26 21:39   ` Reinette Chatre
2023-09-15 15:44 ` [PATCH v2 3/6] selftests/resctrl: Move _GNU_SOURCE define into Makefile Ilpo Järvinen
2023-09-26 21:39   ` Reinette Chatre
2023-09-15 15:44 ` [PATCH v2 4/6] selftests/resctrl: Refactor feature check to use resource and feature name Ilpo Järvinen
2023-09-26 21:40   ` Reinette Chatre
2023-09-15 15:44 ` [PATCH v2 5/6] selftests/resctrl: Fix feature checks Ilpo Järvinen
2023-09-26 21:41   ` Reinette Chatre
2023-09-15 15:44 ` [PATCH v2 6/6] selftests/resctrl: Reduce failures due to outliers in MBA/MBM tests Ilpo Järvinen
2023-09-26 21:41   ` Reinette Chatre
2023-09-20 10:13 ` [PATCH v2 0/6] selftests/resctrl: Fixes to failing tests Maciej Wieczór-Retman
2023-09-28  8:18 ` Shaopeng Tan (Fujitsu)

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=TYAPR01MB6330FD62ED8A752ECDA8AF948BCAA@TYAPR01MB6330.jpnprd01.prod.outlook.com \
    --to=tan.shaopeng@fujitsu.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=reinette.chatre@intel.com \
    --cc=shuah@kernel.org \
    --cc=skhan@linuxfoundation.org \
    --cc=stable@vger.kernel.org \
    /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

all inboxes | Powered by JetHome®