High interrupt rate

[b. f.]

On 8/7/11, Mario Lobo <lobo at bsd.com.br> wrote:
> On Sunday 07 August 2011 18:34:27 b. f. wrote:
>> > I know 75% idle is not bad but this machine, when not under load on a
>> > saturday night like today, used to be at around 98% idle 99% of the
>> > time. Now its is at 72% idle 99.9% of the time. It has been like this
>> > all day.
>> >
>> > The only things with a high interrupt rate are
>> >
>> > cpu0: timer                     46922025       2000
>> > cpu1: timer                     46918117       1999
>> >
>> > What could be causing this?
>>
>> I don't know that 2 timer interrupts per-cpu, per kern.hz, is
>> altogether unexpected for some configurations, under some conditions.
>> What happens if you boot with kern.hz="100" in /boot/loader.conf, or
>> set via the loader command line?  What happens if you remove the
>> DEVICE_POLLING option from your kernel (and _not_ just disable polling
>> per-device)?  What is the output from "sysctl kern.timecounter
>> kern.eventtimer"?
>>
>> b.
>
> Thanks b. !
>
> [~]>sysctl kern.timecounter
> kern.timecounter.tick: 1
> kern.timecounter.choice: TSC(-100) ACPI-safe(850) i8254(0) dummy(-1000000)
> kern.timecounter.hardware: ACPI-safe
> kern.timecounter.stepwarnings: 0
> kern.timecounter.tc.i8254.mask: 65535
> kern.timecounter.tc.i8254.counter: 39201
> kern.timecounter.tc.i8254.frequency: 1193182
> kern.timecounter.tc.i8254.quality: 0
> kern.timecounter.tc.ACPI-safe.mask: 16777215
>
>
> kern.timecounter.tc.ACPI-safe.counter: 1055460
>
>
> kern.timecounter.tc.ACPI-safe.frequency: 3579545
>
>
> kern.timecounter.tc.ACPI-safe.quality: 850
>
>
> kern.timecounter.tc.TSC.mask: 4294967295
>
>
> kern.timecounter.tc.TSC.counter: 1200011080
>
>
> kern.timecounter.tc.TSC.frequency: 1995401152
>
>
> kern.timecounter.tc.TSC.quality: -100
>
>
> kern.timecounter.smp_tsc: 0
>
>
> kern.timecounter.invariant_tsc: 1
>
> [~]>sysctl kern.hz
> kern.hz: 1000
>
> [~]>sysctl kern.eventtimer
> sysctl: unknown oid 'kern.eventtimer'
>
> I'll wait for your views on those before disabling polling on the kernel and
> hz=100.

It looks like your interrupt rate, while probably higher than needed,
is not unexpectedly high for your configuration.  But you can lower it
if you want to do so.

You are using a system before the introduction of the new eventtimer
code.  If you use 9.x, that has the new code and some other
timer-related improvements, and you are not performing polling, then
you can achieve a large reduction in the number of timer interrupts
when the system isn't busy. You can still achieve a reduction on 8.x,
but the reduction usually won't be as large as on 9.x under similar
conditions.

To reduce timer interrupts on an idle system running 8.x or 9.x, if
you do not need to poll (most systems do not), remove  DEVICE_POLLING
from your kernel, and lower kern.hz to a suitable value -- 100 or 250,
for example. For many workloads, a lower value is not only adequate,
but may also be better in some ways.

Also, you may want to consider using your TSC as the system
timecounter, because it is usually more efficient to do so.  This may
not work for SMP, because if there are multiple TSCs on your system,
they may not be synchronized.  In 9.x, there is a test for
synchronization, and the TSCs are preferred to the ACPI-safe timer if
they satisfy this test and meet some other requirements.  In 8.x, the
user has to tell the system that it is safe to use the TSCs by adding:

kern.timecounter.smp_tsc="1"

to /boot/loader.conf.  If you are not putting your cores into the C3
state, then you could try setting this via the loader command line,
booting, and then seeing if the kern.timecounter.tc.TSC.quality is
positive, kern.timecounter.hardware is TSC, and everything is working
as expected.  If the results are satisfactory, then you could add the
above entry to /boot/loader.conf.  But it would be better to do this
on 9.x, where there are some added safeguards.

b.