Request for information - timers, hz, interrupts

[Ivan Voras]

For a long time, at least in the 6-stable timeframe, I was used to
seeing timer interrupts going at the frequency of 2*HZ, e.g. this is
from 6.4-RELEASE:

kern.clockrate: { hz = 250, tick = 4000, profhz = 166, stathz = 33 }
debug.psm.hz: 20

cpu0: timer 6789885563 499
cpu2: timer 6789885538 499
cpu1: timer 6789885538 499
cpu3: timer 6789885537 499

Then sometime in 7.x this changed to 4*HZ, which continues in 8.x, e.g.
from 7.2-RELEASE:

kern.clockrate: { hz = 250, tick = 4000, profhz = 1000, stathz = 142 }
kern.hz: 250

cpu0: timer 1368329715 988
cpu1: timer 1368324640 988
cpu2: timer 1367642854 988
cpu3: timer 1367642874 988

I'm not very worried about it (though maybe laptop users might be
because of potential power drainage) but would like to know the
explanation behind it.

Presumably it has something to do with profhz but what and why? There
isn't an obvious correlation between profhz frequency in 6.x and HZ and
in 7.x. and HZ.

_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"

[John Baldwin]

On Friday 04 December 2009 9:52:39 am Ivan Voras wrote:
> For a long time, at least in the 6-stable timeframe, I was used to
> seeing timer interrupts going at the frequency of 2*HZ, e.g. this is
> from 6.4-RELEASE:
>
> kern.clockrate: { hz = 250, tick = 4000, profhz = 166, stathz = 33 }
> debug.psm.hz: 20
>
> cpu0: timer 6789885563 499
> cpu2: timer 6789885538 499
> cpu1: timer 6789885538 499
> cpu3: timer 6789885537 499
>
> Then sometime in 7.x this changed to 4*HZ, which continues in 8.x, e.g.
> from 7.2-RELEASE:
>
> kern.clockrate: { hz = 250, tick = 4000, profhz = 1000, stathz = 142 }
> kern.hz: 250
>
> cpu0: timer 1368329715 988
> cpu1: timer 1368324640 988
> cpu2: timer 1367642854 988
> cpu3: timer 1367642874 988
>
> I'm not very worried about it (though maybe laptop users might be
> because of potential power drainage) but would like to know the
> explanation behind it.
>
> Presumably it has something to do with profhz but what and why? There
> isn't an obvious correlation between profhz frequency in 6.x and HZ and
> in 7.x. and HZ.

It actually was changed to provide saner behavior when you use low hz values
like 'hz=100'. Note that your stathz is now 142 instead of 33. The scheduler
is likely far happier with that stathz. There is more detail in the commit
log I believe (just look at the logs for local_apic.c in either svn or
cvsweb).

--
John Baldwin

[John Baldwin]

On Friday 04 December 2009 4:09:59 pm Ivan Voras wrote:
> 2009/12/4 John Baldwin <j...@freebsd.org>:

> > On Friday 04 December 2009 9:52:39 am Ivan Voras wrote:
> >> For a long time, at least in the 6-stable timeframe, I was used to
> >> seeing timer interrupts going at the frequency of 2*HZ, e.g. this is
> >> from 6.4-RELEASE:
> >>

> >> kern.clockrate: { hz = 250, tick = 4000, profhz = 1000, stathz = 142 }
> >> kern.hz: 250
>

> > It actually was changed to provide saner behavior when you use low hz values
> > like 'hz=100'. Note that your stathz is now 142 instead of 33. The scheduler
> > is likely far happier with that stathz. There is more detail in the commit
> > log I believe (just look at the logs for local_apic.c in either svn or
> > cvsweb).
>

> Ok. Some more questions:
>
> What does "ticks" do in the above sysctl output?

'tick' is the number of microseconds per clock tick. Since you run hz at 250,
that gives you 4ms = 4000us per clock tick.

> So 4000 interrupts/s per CPU in the default configuration isn't
> considered excessive? :)

The default configuration is hz = 1000 which gives you an interrupt rate of
2000 interrupts/s per CPU and a stathz of 133. With your setting of hz=250,
you have an interrupt rate of 1000 interrupts/s per CPU.

> I see stathz isn't a divisor of any number in kern.clockrate, which
> probably means it's not triggered from one of them firing; can't it be
> a separately configurable value?

No, it is driven by the tick timer. It ends up running at something more
like 142.8571428571 when you have hz = 250. (So some seconds it will fire
143 times rather than 142.)

The kernel tries to run stathz as close to 128 as possible, but ~142 is
what it comes up with. It should probably try the next divisor "up" and
take the resulting stathz that is the closest to 128. That would let stathz
run at 125 on your machine instead of ~142.

[Phillip Spring]

fact:

I had to clean up a motherboard to boot Suse 10.2 kernel.

I think that dust and dead insects are for Windows 2003 only.

dog -- now with the right sender name :)

> To: freebsd...@freebsd.org
> From: ivo...@freebsd.org
> Date: Fri, 4 Dec 2009 15:52:39 +0100
> Subject: Request for information - timers, hz, interrupts

_________________________________________________________________
Windows 7: agora com conex�es autom�ticas de rede. Conhe�a.
http://www.microsoft.com/brasil/windows7/default.html?WT.mc_id=1539_______________________________________________