Date: Wed, 7 Dec 2005 03:51:47 -0800 From: "Ed" <ed@edslocomb.com> To: "Peter Jeremy" <PeterJeremy@optushome.com.au> Cc: freebsd-stable@freebsd.org Subject: Re: cpu-timer rate Message-ID: <002b01c5fb24$9a802150$1132e7d8@robotslave> References: <20051205124910.GC90806@over-yonder.net><20051205181552.2D7AB5D04@ptavv.es.net> <20051207071710.GQ32006@cirb503493.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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@optushome.com.au> To: "Kevin Oberman" <oberman@es.net> Cc: "kama" <kama@pvp.se>; <freebsd-stable@freebsd.org>; "Matthew D. Fuller" <fullermd@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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?002b01c5fb24$9a802150$1132e7d8>