Date: Sun, 7 Mar 2021 14:59:27 -0800 From: Mark Millard <marklmi@yahoo.com> To: yasu@utahime.org, freebsd-current <freebsd-current@freebsd.org> Subject: Re: Waiting for bufdaemon Message-ID: <54E0DAB6-FE34-4BE9-97EA-DFA1F6C2244D@yahoo.com> In-Reply-To: <DDC414A9-108B-43F1-A8FC-1DE22393A386@yahoo.com> References: <DDC414A9-108B-43F1-A8FC-1DE22393A386@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Mar-5, at 17:35, Mark Millard <marklmi at yahoo.com> wrote:
> Yasuhiro Kimura yasu at utahime.org wrote on
> Fri Mar 5 23:34:59 UTC 2021 :
>=20
>> From: Konstantin Belousov <kostikbel at gmail.com>
>> Subject: Re: Waiting for bufdaemon
>> Date: Fri, 5 Mar 2021 22:43:58 +0200
>>=20
>>> My belief is that this commit helps more users than it hurts. =
Namely,
>>> the VMWare and KVM users, which are majority, use fast timecounter,
>>> comparing to the more niche hypervisors like VirtualBox.
>>>=20
>>> For you, a simple but manual workaround, setting the timecounter to
>>> ACPI (?) or might be HPET, with a loader tunable, should do it.
>>=20
>> Then please let me know the name of it.
>>=20
>> I have experienced same situation several time. That is, I faced a
>> problem and asked for it on ML. Then I was told to try some tunable.
>> So I thought there may be tunable that can be used as workaround in
>> this case. But for those who isn't familiar with kernel internal, it
>> it quite hard to find it without knowing its name. If all tunable =
were
>> listed with brief explanation in one document, then I saw it and =
could
>> pick up possible candidates. But actually they are documented
>> separately among many man pages. So the first difficulty is to find
>> man page in which possible tunable may be explained. If the problem =
is
>> releted to some device, it is most hopeful to check its man page. But
>> in this case, even after reading the commit message, I had no idea
>> which man page to check.
>=20
> Its somewhat messy but there is a technique of using
> the "timecounter" in kib's wording to explore:
>=20
> # sysctl -a | grep -i timecounter
> kern.timecounter.tsc_shift: 1
> kern.timecounter.smp_tsc_adjust: 0
> kern.timecounter.smp_tsc: 1
> kern.timecounter.invariant_tsc: 1
> kern.timecounter.fast_gettime: 1
> kern.timecounter.tick: 1
> kern.timecounter.choice: ACPI-fast(900) i8254(0) HPET(950) =
TSC-low(1000) dummy(-1000000)
> kern.timecounter.hardware: TSC-low
> kern.timecounter.alloweddeviation: 5
> kern.timecounter.timehands_count: 2
> kern.timecounter.stepwarnings: 0
> kern.timecounter.tc.ACPI-fast.quality: 900
> kern.timecounter.tc.ACPI-fast.frequency: 3579545
> kern.timecounter.tc.ACPI-fast.counter: 3054367693
> kern.timecounter.tc.ACPI-fast.mask: 4294967295
> kern.timecounter.tc.i8254.quality: 0
> kern.timecounter.tc.i8254.frequency: 1193182
> kern.timecounter.tc.i8254.counter: 43913
> kern.timecounter.tc.i8254.mask: 65535
> kern.timecounter.tc.HPET.quality: 950
> kern.timecounter.tc.HPET.frequency: 14318180
> kern.timecounter.tc.HPET.counter: 3575335307
> kern.timecounter.tc.HPET.mask: 4294967295
> kern.timecounter.tc.TSC-low.quality: 1000
> kern.timecounter.tc.TSC-low.frequency: 1696849832
> kern.timecounter.tc.TSC-low.counter: 590106679
> kern.timecounter.tc.TSC-low.mask: 4294967295
>=20
> Given the references to ACPI and HPET in kib's
> wording, notable seems to be (from one of my
> contexts):
>=20
> kern.timecounter.choice: ACPI-fast(900) i8254(0) HPET(950) =
TSC-low(1000) dummy(-1000000)
> kern.timecounter.hardware: TSC-low
>=20
> The descriptions of those two look like:
>=20
> # sysctl -ad kern.timecounter.choice kern.timecounter.hardware
> kern.timecounter.choice: Timecounter hardware detected
> kern.timecounter.hardware: Timecounter hardware selected
>=20
> The "selected" wording suggests that kern.timecounter.hardware
> might be able to be assigned --and kib's wording would imply
> that it can be.
>=20
> Looking at the descriptions without also looking at the
> values need not be clear:
>=20
> # sysctl -ad | grep -i timecounter
> kern.timecounter:=20
> kern.timecounter.tsc_shift: Shift to pre-apply for the maximum TSC =
frequency
> kern.timecounter.smp_tsc_adjust: Try to adjust TSC on APs to match BSP
> kern.timecounter.smp_tsc: Indicates whether the TSC is safe to use in =
SMP mode
> kern.timecounter.invariant_tsc: Indicates whether the TSC is P-state =
invariant
> kern.timecounter.fast_gettime: Enable fast time of day
> kern.timecounter.tick: Approximate number of hardclock ticks in a =
millisecond
> kern.timecounter.choice: Timecounter hardware detected
> kern.timecounter.hardware: Timecounter hardware selected
> kern.timecounter.alloweddeviation: Allowed time interval deviation in =
percents
> kern.timecounter.timehands_count: Count of timehands in rotation
> kern.timecounter.stepwarnings: Log time steps
> kern.timecounter.tc:=20
> kern.timecounter.tc.ACPI-fast: timecounter description
> kern.timecounter.tc.ACPI-fast.quality: goodness of time counter
> kern.timecounter.tc.ACPI-fast.frequency: timecounter frequency
> kern.timecounter.tc.ACPI-fast.counter: current timecounter value
> kern.timecounter.tc.ACPI-fast.mask: mask for implemented bits
> kern.timecounter.tc.i8254: timecounter description
> kern.timecounter.tc.i8254.quality: goodness of time counter
> kern.timecounter.tc.i8254.frequency: timecounter frequency
> kern.timecounter.tc.i8254.counter: current timecounter value
> kern.timecounter.tc.i8254.mask: mask for implemented bits
> kern.timecounter.tc.HPET: timecounter description
> kern.timecounter.tc.HPET.quality: goodness of time counter
> kern.timecounter.tc.HPET.frequency: timecounter frequency
> kern.timecounter.tc.HPET.counter: current timecounter value
> kern.timecounter.tc.HPET.mask: mask for implemented bits
> kern.timecounter.tc.TSC-low: timecounter description
> kern.timecounter.tc.TSC-low.quality: goodness of time counter
> kern.timecounter.tc.TSC-low.frequency: timecounter frequency
> kern.timecounter.tc.TSC-low.counter: current timecounter value
> kern.timecounter.tc.TSC-low.mask: mask for implemented bits
>=20
> Looking at both can tend to narrow things down.
>=20
> Not exactly direct, but useful. It might have been
> harder before having kib's wording that used
> terminology (notation) involved in the use of the
> systctl commands.
>=20
> I'll note that in the context I'm using for this:
>=20
> # sysctl -ad | wc
> 11153 57922 604736
>=20
> # sysctl -a | wc
> 13080 29457 449667
>=20
> So: not a trivial amount of material.
>=20
Kyle Evens' message points out that I inappropriately
did not cover some sysctl command line options that
are useful:
-T Display only variables that are settable via loader
(CTLFLAG_TUN).
and:
-W Display only writable variables that are not statistical. =
Useful
for determining the set of runtime tunable sysctls.
So:
# sysctl -aT | grep timecounter
kern.timecounter.tsc_shift: 1
kern.timecounter.smp_tsc_adjust: 0
kern.timecounter.smp_tsc: 1
kern.timecounter.invariant_tsc: 1
kern.timecounter.alloweddeviation: 5
kern.timecounter.timehands_count: 2
# sysctl -aW | grep timecounter
kern.timecounter.fast_gettime: 1
kern.timecounter.hardware: TSC-low
kern.timecounter.alloweddeviation: 5
kern.timecounter.stepwarnings: 0
(kern.timecounter.choice is not settable and so
is not in either list. But I do not see an
option for listing read-only, non-loader-tunable
variables separately.)
Between the -aT output and the -aW output,
it indicates that /etc/sysctl.conf is appropriate
for kern.timecounter.hardware assignment but
/boot/loader.conf is not: writable but not a loader
tunable.
For reference:
# sysctl -aT | wc
768 1519 20989
# sysctl -aW | wc
1506 3130 44717
(Some may be in both lists.)
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54E0DAB6-FE34-4BE9-97EA-DFA1F6C2244D>