Date: Fri, 4 Dec 2009 17:32:49 -0500 From: John Baldwin <jhb@freebsd.org> To: Ivan Voras <ivoras@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Request for information - timers, hz, interrupts Message-ID: <200912041732.50026.jhb@freebsd.org> In-Reply-To: <9bbcef730912041309m51ce4858q42937e0f76f94cda@mail.gmail.com> References: <hfb7ne$mi$1@ger.gmane.org> <200912041047.08253.jhb@freebsd.org> <9bbcef730912041309m51ce4858q42937e0f76f94cda@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 04 December 2009 4:09:59 pm Ivan Voras wrote:
> 2009/12/4 John Baldwin <jhb@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.
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200912041732.50026.jhb>