Re: RFC: New event timers infrastructure

Brandon Gooch wrote:
> On Sun, Jun 20, 2010 at 1:17 AM, Alexander Motin <mav_at_freebsd.org> wrote:
> In by /boot/loader.conf, I now have:
> 
> # Power Saving
> kern.hz="100"
> #hint.apic.0.clock="0"
> #hint.atrtc.0.clock="0"
> hint.p4tcc.0.disabled="1"
> hint.p4tcc.1.disabled="1"
> hint.acpi_throttle.0.disabled="1"
> hint.acpi_throttle.1.disabled="1"
> hw.pci.do_power_nodriver="3"
> 
> In /etc/sysctl.conf, I have as suggested:
> 
> kern.eventtimer.timer1=HPET
> kern.eventtimer.timer2=NONE
> kern.eventtimer.singlemul=1

While this can be done in sysctl.conf, it would be better to do it in
loader.conf to make it applied from the beginning, without on-the-fly
timers change.

> But in my dmesg, I see:
> 
> # dmesg | grep Starting
> Starting kernel event timers: LAPIC _at_ 100Hz, HPET _at_ 128Hz
> Starting kernel event timers: LAPIC _at_ 400Hz, NONE _at_ 0Hz
> Starting kernel event timers: HPET _at_ 200Hz, NONE _at_ 0Hz

This is result of changing timers during late boot by sysctl.conf.

> So it seems as if the HPET doesn't honor kern.hz setting? Maybe I
> still need to explicitly disable the apic timers...

All timers now equally honor hz. But except hz, stathz also should be
honored, which set once during startup. In your case, as second timer
was initially present, system was free to choose stathz frequency, and
it chosen 128Hz. When you later disabled second timer, system had to
rise first timer frequency to emulate declared stathz.

If you move timers selection options from sysctl.conf to loader.conf you
will get what you want.

> Would you suggest using LAPIC as opposed to HPET? I have seen power
> savings being able to use C3 state, but if tickless kernel eventually
> buys those savings back, perhaps LAPIC would be better...

Tickless operation usually effective only together with C-states. It
increases their effectiveness (or even applicability). The only case
benefit from tickless operation without C3 - is a virtual machines.

So if your LAPIC dies on C3 (it seems not to on Core i5 any more) you
have no much other options then avoid it.

HPET same time never have problems with C-states, as it located in
chipset. But not every HPET is equally useful. Except AMD since at least
SB700) and latest Intel chipsets, HPET uses regular IRQs, that are often
shared with PCI devices and so hardly could be bound to CPU cores to
provide separate events for every core. While tickless operation is
still possible in that case, it is somewhat limited, as one core will
have wake up every time when any other need event. Mentioned chipset's
HPETs same time support FSB interrupts (alike to PCI MSI-X), that are
never shared and so timers could be dedicated to CPU cores.

>> As result, you will have single timer, running at HZ rate. Instead of
>> HPET there you may choose any timer:
>>  LAPIC - it is per-CPU, so saves on IPI interrupts, supports one-shot
>> mode and so suitable for further tickless kernel, but it doesn't work in
>> C3 state;
> 
> So if LAPIC is disabled in C3 state, is there a possibility that the
> "on-the-fly" method of changing clocks could kick in when the CPU
> enters C3 state, switching to the HPET when it happens?

On-the-fly timers change is possible, as you have already tried with
sysctl.conf. But the switch is not so easy because of LAPIC specifics,
and it is meaningless to use LAPIC in that case. If you need to run C3 -
turn LAPIC off.

-- 
Alexander Motin