What value HZ?

[Ian Lepore]

On Sat, 2019-09-07 at 18:58 -0700, Conrad Meyer wrote:
> Hi Constantine,
> 
> On Sat, Sep 7, 2019 at 3:05 PM Constantine A. Murenin
> <cnst++ at freebsd.org> wrote:
> > 
> > For the sake of discussion, I recall that there was a measurable power
> > consumption difference between FreeBSD (HZ=1000) and OpenBSD (HZ=100) when
> > I played with a Kill-A-Watt a number of years ago.
> 
> Unfortunately, this is an apples to oranges comparison, and perhaps
> worse, vague and dated.  It would be more interesting to compare
> HZ=1000 to HZ=100 with an otherwise identical CURRENT FreeBSD system.
> 
> As far as I can tell, FreeBSD grew "tickless" timer support in r212541
> in 2010 (thanks mav@).  This is easily observed on my idle HZ=1000
> amd64 system with 'vmstat -i': "cpu0:timer" is firing at an average
> rate of 21 Hz — not 1000.  And that is the most frequent interrupt.
> 
> > Would it perhaps be prudent to try to qualify whether, and by how much,
> > this change affects power consumption on MIPS/ARM/RISCV, not just whether
> > each arch could cope with the change?
> 
> If someone has the time and inclination, then of course, it could be
> an interesting test to run.

In this mail, when I say HZ, I mean also 'hz' the global var that's
tunable...

When I saw this conversation moved to arch@ my first thought was "Good,
we can finally have the conversation I've been trying to have with
people for years."  But, alas, the focus even here is still just "100
vs 1000", not the base question I really want to see answered.  I'm
replying to this message in the thread because it comes closest to
touching on that base question, which is:

   What, exactly, does HZ control and affect these days?

It no longer controls how often periodic timer interrupts happen,
except on a few rare systems that don't support one-shot style event
timers.  I'm not sure any such systems even still exist, now that we've
nuked most of the old armv4 support.  If they do exist, I'm pretty sure
it's only in the MIPS arch.

It no longer controls the scheduling quantum for a process or thread. 
Or so I've been told, I'm pretty ignorant about the workings of both
schedulers.

It no longer controls the minimum amount of time a userland process can
sleep when calling the usleep() or nanosleep() functions.

The one thing I know for sure that HZ affects is whatever code still
exists that schedules timeouts in terms of 'ticks' rather than using
the newer SBT flavor of sleeping functions.  Old-school pause(9) and
msleep(9) and others that take a timeout in 'ticks' will have the
timeout granularity implied by HZ, and there is still such code around
in various device drivers and other places.

Aside from old-school tick-based sleep functions, does HZ do anything
anymore?

-- Ian