cpu-timer rate
Ed
ed at edslocomb.com
Wed Dec 7 03:52:21 PST 2005
I certainly do not have a full understanding of the interactions between the
various FreeBSD software timers and i386 hardware clocks, but I do know this
is not the first time we've seen a problem with the APIC/ACPI timers/clocks.
See here:
http://www.freebsd.org/cgi/getmsg.cgi?fetch=643512+646009+/usr/local/www/db/text/2005/freebsd-stable/20051120.freebsd-stable
And workaround, here:
http://www.freebsd.org/cgi/getmsg.cgi?fetch=687445+690193+/usr/local/www/db/text/2005/freebsd-stable/20051120.freebsd-stable
I haven't made much of a fuss, since my vmware FreeBSD works just fine so
long as I disable the APIC (not ACPI) device. I was guessing there was some
assumption about relative rates gumming things up for vmware (the hardware
APIC (not ACPI) timer runs at memory bus speed, not cpu speed, and thus will
get goofed if you assume straight/DDR/quad/whatever memory-- from what I
gather, you need to check it against a known-hz device, e.g. the PIT/i8253
clock).
My complacency, however, is probably misguided, as the release notes for 6.0
clearly sate that "FreeBSD always uses the local APIC timer even on
uni-processor systems now," and will presumably continue to do so for the
forseeable future.
There is a nice layman's overview of various i386 hardware clock devices
here:
http://www.vmware.com/pdf/vmware_timekeeping.pdf
Again, I'm no expert, but clock problems do keep cropping up here on
the -STABLE list, and the explanations for them to date have not been
consistent. This leads me to believe that the FreeBSD kernel clock/timer
code is not well-understood by any one developer who monitors this list; I'm
sure I'm not the only end-user who would appreciate it if the core team
would look into this and post some information that would explain the
various clock/timer problems that odd corners of the user community have
been reporting.
----- Original Message -----
From: "Peter Jeremy" <PeterJeremy at optushome.com.au>
To: "Kevin Oberman" <oberman at es.net>
Cc: "kama" <kama at pvp.se>; <freebsd-stable at freebsd.org>; "Matthew D. Fuller"
<fullermd at over-yonder.net>
Sent: Tuesday, December 06, 2005 11:17 PM
Subject: Re: cpu-timer rate
> On Mon, 2005-Dec-05 10:15:52 -0800, Kevin Oberman wrote:
>>> On Mon, Dec 05, 2005 at 09:42:08AM +0100 I heard the voice of
>>> kama, and lo! it spake thus:
>>> >
>>> > I appreciate that you took time to answer about the different
>>> > clocks. But that does not answer why vmstat -i shows a rate of 2000
>>> > when I have set the hz to 1000.
>>>
>>> Because the rate is always twice hz.
>>
>>While I will concede that I have no explanation, but on all of my systems
>>rate = HZ +/-1. I have never seen a case where rate/2 = HZ.
>
> Basically, it depends on what clock(s) your kernel is using.
>
> Traditionally, FreeBSD/i386 uses the one of the i8254 counters to
> generate hz (on irq0) and the RTC to generate profhz/stathz (on irq8).
> In this case, the rate on those interrupts should match the values
> reported by kern.clockrate. On SMP machines, this approach is fairly
> expensive because the interrupts need to be forwarded to all CPUs
> using IPIs.
>
> In early February, jhb implemented an alternative approach using the
> local APIC clock (sys/i386/i386/local_apic.c v1.13 and other files).
> Since every CPU has a LAPIC, every CPU gets its own clock interrupts
> without needing IPIs. The downside is that there's only a single
> LAPIC so a single hardware clock interrupt needs to generate separate
> (and independent) hz/tick and stathz/profhz clocks.
>
> Since the clocks need to be independent (to make process statistics
> meaningful), this implies that the hardware (LAPIC) clock (cpu0) needs
> to be faster than hz. The original commit ran LAPIC at hz*3 but this
> was later changed to hz*2 to reduce overheads.
>
> --
> Peter Jeremy
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
>
More information about the freebsd-stable
mailing list