LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Paul E. McKenney" <firstname.lastname@example.org>
To: Andi Kleen <email@example.com>
Cc: Matthew Wilcox <firstname.lastname@example.org>,
Feng Tang <email@example.com>,
kernel test robot <firstname.lastname@example.org>,
John Stultz <email@example.com>,
Thomas Gleixner <firstname.lastname@example.org>,
Stephen Boyd <email@example.com>, Jonathan Corbet <firstname.lastname@example.org>,
Mark Rutland <Mark.Rutland@arm.com>,
Marc Zyngier <email@example.com>,
Xing Zhengjun <firstname.lastname@example.org>,
Chris Mason <email@example.com>, LKML <firstname.lastname@example.org>,
Linux Memory Management List <email@example.com>,
firstname.lastname@example.org, email@example.com, firstname.lastname@example.org,
Subject: Re: [clocksource] 8901ecc231: stress-ng.lockbus.ops_per_sec -9.5% regression
Date: Tue, 1 Jun 2021 10:10:01 -0700 [thread overview]
Message-ID: <20210601171001.GN4397@paulmck-ThinkPad-P17-Gen-1> (raw)
On Thu, May 27, 2021 at 05:58:53PM -0700, Andi Kleen wrote:
> > Only those cloud provides making heavy use of the aforementioned "poorly
> > designed" hardware, correct?
> If any such hardware is deployed in non homeopathic quantities, we probably
> need to support it out of the box. So far I'm not seeing any evidence that
> it does not.
> That would argue for including the patch in the patch series.
> Especially since stress-ng is somewhat popular for system testing.
Except that different use cases need different out-of-the-box settings.
In addition, there is a range of consequences for undesired settings
across these use cases. Fortunately, the various distros and other kernel
delivery mechanisms act as different boxes, and can provide their chosen
Of course, it would be better to avoid adding an additional setting.
But as we will see when considering the following use cases and
corresponding consequences, that setting needs to be to mark the
clocksource unstable if that clocksource exhibits persistent read delays,
that is, as the v15 series does -without- the out-of-tree patch.
To see this, consider the following use cases:
o Bringup testing for new silicon, firmware, and clock drivers.
In this case, it is critically important that any serious problem
be unmistakably flagged. After all, these activities are all
too often carried out under severe time pressure, which means
that subtle messages are likely to be ignored. If there is a
hardware, firmware, or driver issue that results in persistent
delays, this issue must not be ignored. Hence the absolute need
to mark the clocksource unstable in this case, in order to avoid
releasing hardware, firmware, and clock-driver bugs into the wild.
o System test for new hardware, including multisocket hardware
such as that denigrated by stress-ng. Although this use case
might prefer that clocksource read delays be ignored (as they
would be with my out-of-tree patch ), there are a number of
good-and-sufficient ways to deal with the current state of the
v15 series , including marking the TSC stable, specifying HPET
at boot time, or simply ignoring the fact that the clocksource
gets marked unstable.
o Applications running in production that suffer from stress-ng-like
properties. Such applications might well prefer that high-speed
fine-grained clocksources not be marked unstable, but the
workarounds for system test apply here as well.
Furthermore, such applications are likely to perform better
on a single-socket system than on a larger and more expensive
multi-socket system. Thus, marking clocksources unstable
would be a good hint that adjustments would be helpful, whether
these adjustments be confining such applications to lower-cost
hardware on which they are likely to perform better, or reading
a certain book  and applying its lessons in order to adjust
the application to improve performance and scalability and to
reduce the interference with clocksources.
o Scalable applications running in production, as in those that do
not suffer from stress-ng-like properties. Any such applications
that are sensitive to clock skew in excess of 100 microseconds
really want the v15 series without the extra patch. After all,
if there is a problem with clock-related hardware, firmware,
or device-driver bugs, it is far better to have that problem
unambiguously diagnosed than to have to wade through strange
and misleading application problems caused by clock skew.
And please note that this is not a theoretical problem.
After all, an earlier version of this series already spotted a
very real problem that was addressed by an upgrade.
So if there is only a single out-of-the box option, it really does need
to be that provided by v15 of the patch series. There are already
settings that can be used in the use cases that care, but if these
prove inadequate, again, I can add another setting via a new patch,
perhaps based on my out-of-tree patch.
next prev parent reply other threads:[~2021-06-01 17:10 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-21 8:33 kernel test robot
2021-05-21 13:56 ` Paul E. McKenney
2021-05-22 16:08 ` Paul E. McKenney
2021-05-26 6:49 ` Feng Tang
2021-05-26 13:49 ` Paul E. McKenney
2021-05-27 18:29 ` Paul E. McKenney
2021-05-27 19:01 ` Andi Kleen
2021-05-27 19:19 ` Paul E. McKenney
2021-05-27 19:29 ` Matthew Wilcox
2021-05-27 21:05 ` Paul E. McKenney
2021-05-28 0:58 ` Andi Kleen
2021-06-01 17:10 ` Paul E. McKenney [this message]
2021-08-02 6:20 ` Chao Gao
2021-08-02 17:02 ` Paul E. McKenney
2021-08-03 8:58 ` Chao Gao
2021-08-03 13:48 ` Paul E. McKenney
2021-08-05 2:16 ` Chao Gao
2021-08-05 4:03 ` Paul E. McKenney
2021-08-05 4:34 ` Andi Kleen
2021-08-05 15:33 ` Paul E. McKenney
2021-08-05 5:39 ` Chao Gao
2021-08-05 15:37 ` Paul E. McKenney
2021-08-06 2:10 ` Chao Gao
2021-08-06 4:15 ` Paul E. McKenney
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [clocksource] 8901ecc231: stress-ng.lockbus.ops_per_sec -9.5% regression' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).