Re: Waiting for bufdaemon

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.

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