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" <[EMAIL PROTECTED]>
To: "Kevin Oberman" <[EMAIL PROTECTED]>
Cc: "kama" <[EMAIL PROTECTED]>; <freebsd-stable@freebsd.org>; "Matthew D. Fuller"
<[EMAIL PROTECTED]>
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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
