All of lore.kernel.org
 help / color / mirror / Atom feed
From: mingo at kernel.org (Ingo Molnar)
Subject: [PATCH 2/2] selftests/x86/fsgsbase: Default to trying to run the test repeatedly
Date: Mon, 11 Feb 2019 13:51:46 +0100	[thread overview]
Message-ID: <20190211125146.GA66987@gmail.com> (raw)
In-Reply-To: <20190211124738.GA22391@sirena.org.uk>


* Mark Brown <broonie at kernel.org> wrote:

> On Mon, Feb 11, 2019 at 09:49:16AM +0100, Ingo Molnar wrote:
> 
> > So this isn't very user-friendly either, previously it would run a 
> > testcase and immediately provide output.
> 
> > Now it's just starting and 'hanging':
> 
> >   galatea:~/linux/linux/tools/testing/selftests/x86> ./fsgsbase_64 
> 
> > I got bored and Ctrl-C-ed it after ~30 seconds.
> 
> > How long is this supposed to run, and why isn't the user informed?
> 
> On Intel systems I've got access to it's tended to only run for less
> than 10 seconds for me with excursions up to ~30s at most, I'd have
> projected it to be about a minute if the tests pass.  However retesting
> with Debian's v4.19 kernel it seems to be running a lot more stably so
> we're now seeing it run to completion reliably when just one copy of the
> test is running.
> 
> AFAICT it's not terribly idiomatic to provide much output, and anything
> that was per iteration would be *way* too spammy.

Certainly - but a "please wait" and updating the current count via \r 
once every second isn't spammy.

> > Also, testcases should really be short, so I think a better approach 
> > would be to thread the test-case and start an instance on every CPU. That 
> > should also excercise SMP bugs, if any.
> 
> Well, a *better* approach would be for the underlying issue that the
> test is finding to be fixed.
> 
> I didn't look at adding more threads as the test case is already
> threaded, it does seem that running multiple copies simultaneously makes
> things reproduce more quickly so it's definitely useful though it's
> still taking multiple iterations.

multiple iterations are fine - waiting a minute with zero output on the 
console isn't.

Thanks,

	Ingo

WARNING: multiple messages have this Message-ID (diff)
From: mingo@kernel.org (Ingo Molnar)
Subject: [PATCH 2/2] selftests/x86/fsgsbase: Default to trying to run the test repeatedly
Date: Mon, 11 Feb 2019 13:51:46 +0100	[thread overview]
Message-ID: <20190211125146.GA66987@gmail.com> (raw)
Message-ID: <20190211125146.fa1T7mIdFjHZBYxx8t3H1q54bWigm55aAXwhJyUsWG4@z> (raw)
In-Reply-To: <20190211124738.GA22391@sirena.org.uk>


* Mark Brown <broonie@kernel.org> wrote:

> On Mon, Feb 11, 2019@09:49:16AM +0100, Ingo Molnar wrote:
> 
> > So this isn't very user-friendly either, previously it would run a 
> > testcase and immediately provide output.
> 
> > Now it's just starting and 'hanging':
> 
> >   galatea:~/linux/linux/tools/testing/selftests/x86> ./fsgsbase_64 
> 
> > I got bored and Ctrl-C-ed it after ~30 seconds.
> 
> > How long is this supposed to run, and why isn't the user informed?
> 
> On Intel systems I've got access to it's tended to only run for less
> than 10 seconds for me with excursions up to ~30s at most, I'd have
> projected it to be about a minute if the tests pass.  However retesting
> with Debian's v4.19 kernel it seems to be running a lot more stably so
> we're now seeing it run to completion reliably when just one copy of the
> test is running.
> 
> AFAICT it's not terribly idiomatic to provide much output, and anything
> that was per iteration would be *way* too spammy.

Certainly - but a "please wait" and updating the current count via \r 
once every second isn't spammy.

> > Also, testcases should really be short, so I think a better approach 
> > would be to thread the test-case and start an instance on every CPU. That 
> > should also excercise SMP bugs, if any.
> 
> Well, a *better* approach would be for the underlying issue that the
> test is finding to be fixed.
> 
> I didn't look at adding more threads as the test case is already
> threaded, it does seem that running multiple copies simultaneously makes
> things reproduce more quickly so it's definitely useful though it's
> still taking multiple iterations.

multiple iterations are fine - waiting a minute with zero output on the 
console isn't.

Thanks,

	Ingo

WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: Shuah Khan <shuah@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H . Peter Anvin" <hpa@zytor.com>,
	Andy Lutomirski <luto@amacapital.net>,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	linux-kselftest@vger.kernel.org, Dan Rue <dan.rue@linaro.org>
Subject: Re: [PATCH 2/2] selftests/x86/fsgsbase: Default to trying to run the test repeatedly
Date: Mon, 11 Feb 2019 13:51:46 +0100	[thread overview]
Message-ID: <20190211125146.GA66987@gmail.com> (raw)
In-Reply-To: <20190211124738.GA22391@sirena.org.uk>


* Mark Brown <broonie@kernel.org> wrote:

> On Mon, Feb 11, 2019 at 09:49:16AM +0100, Ingo Molnar wrote:
> 
> > So this isn't very user-friendly either, previously it would run a 
> > testcase and immediately provide output.
> 
> > Now it's just starting and 'hanging':
> 
> >   galatea:~/linux/linux/tools/testing/selftests/x86> ./fsgsbase_64 
> 
> > I got bored and Ctrl-C-ed it after ~30 seconds.
> 
> > How long is this supposed to run, and why isn't the user informed?
> 
> On Intel systems I've got access to it's tended to only run for less
> than 10 seconds for me with excursions up to ~30s at most, I'd have
> projected it to be about a minute if the tests pass.  However retesting
> with Debian's v4.19 kernel it seems to be running a lot more stably so
> we're now seeing it run to completion reliably when just one copy of the
> test is running.
> 
> AFAICT it's not terribly idiomatic to provide much output, and anything
> that was per iteration would be *way* too spammy.

Certainly - but a "please wait" and updating the current count via \r 
once every second isn't spammy.

> > Also, testcases should really be short, so I think a better approach 
> > would be to thread the test-case and start an instance on every CPU. That 
> > should also excercise SMP bugs, if any.
> 
> Well, a *better* approach would be for the underlying issue that the
> test is finding to be fixed.
> 
> I didn't look at adding more threads as the test case is already
> threaded, it does seem that running multiple copies simultaneously makes
> things reproduce more quickly so it's definitely useful though it's
> still taking multiple iterations.

multiple iterations are fine - waiting a minute with zero output on the 
console isn't.

Thanks,

	Ingo

  reply	other threads:[~2019-02-11 12:51 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-03 13:40 [PATCH 0/2] Make fsgsbase test more stable broonie
2019-02-03 13:40 ` Mark Brown
2019-02-03 13:40 ` Mark Brown
2019-02-03 13:40 ` [PATCH 1/2] selftests/x86/fsgsbase: Indirect output through a wrapper function broonie
2019-02-03 13:40   ` Mark Brown
2019-02-03 13:40   ` Mark Brown
2019-02-11  8:45   ` mingo
2019-02-11  8:45     ` Ingo Molnar
2019-02-11  8:45     ` Ingo Molnar
2019-02-11 13:02     ` broonie
2019-02-11 13:02       ` Mark Brown
2019-02-11 13:02       ` Mark Brown
2019-02-03 13:40 ` [PATCH 2/2] selftests/x86/fsgsbase: Default to trying to run the test repeatedly broonie
2019-02-03 13:40   ` Mark Brown
2019-02-03 13:40   ` Mark Brown
2019-02-11  8:49   ` mingo
2019-02-11  8:49     ` Ingo Molnar
2019-02-11  8:49     ` Ingo Molnar
2019-02-11 12:47     ` broonie
2019-02-11 12:47       ` Mark Brown
2019-02-11 12:47       ` Mark Brown
2019-02-11 12:51       ` mingo [this message]
2019-02-11 12:51         ` Ingo Molnar
2019-02-11 12:51         ` Ingo Molnar

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=20190211125146.GA66987@gmail.com \
    --to=unknown@example.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.