Re: Waiting for bufdaemon

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 :
> 
>> From: Konstantin Belousov <kostikbel at gmail.com>
>> Subject: Re: Waiting for bufdaemon
>> Date: Fri, 5 Mar 2021 22:43:58 +0200
>> 
>>> 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.
>>> 
>>> For you, a simple but manual workaround, setting the timecounter to
>>> ACPI (?) or might be HPET, with a loader tunable, should do it.
>> 
>> Then please let me know the name of it.
>> 
>> 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.
> 
> Its somewhat messy but there is a technique of using
> the "timecounter" in kib's wording to explore:
> 
> # 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
> 
> Given the references to ACPI and HPET in kib's
> wording, notable seems to be (from one of my
> contexts):
> 
> kern.timecounter.choice: ACPI-fast(900) i8254(0) HPET(950) TSC-low(1000) dummy(-1000000)
> kern.timecounter.hardware: TSC-low
> 
> The descriptions of those two look like:
> 
> # sysctl -ad kern.timecounter.choice kern.timecounter.hardware
> kern.timecounter.choice: Timecounter hardware detected
> kern.timecounter.hardware: Timecounter hardware selected
> 
> The "selected" wording suggests that kern.timecounter.hardware
> might be able to be assigned --and kib's wording would imply
> that it can be.
> 
> Looking at the descriptions without also looking at the
> values need not be clear:
> 
> # sysctl -ad | grep -i timecounter
> kern.timecounter: 
> 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: 
> 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
> 
> Looking at both can tend to narrow things down.
> 
> 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.
> 
> I'll note that in the context I'm using for this:
> 
> # sysctl -ad | wc
>   11153   57922  604736
> 
> # sysctl -a | wc
>   13080   29457  449667
> 
> So: not a trivial amount of material.
> 

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.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)