Date: Mon, 5 Sep 2005 05:28:59 +1000 From: Peter Jeremy <PeterJeremy@optushome.com.au> To: Emanuel Strobl <Emanuel.strobl@gmx.net> Cc: freebsd-current@freebsd.org, FreeBSD Stable <freebsd-stable@freebsd.org> Subject: Re: HZ option [Was: Re: custom kernel + if_xl + error] Message-ID: <20050904192858.GB77285@cirb503493.alcatel.com.au> In-Reply-To: <200509040427.33471@harrymail> References: <20050904011556.25064.qmail@web25407.mail.ukl.yahoo.com> <200509040427.33471@harrymail>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2005-Sep-04 04:27:24 +0200, Emanuel Strobl wrote:
>standard. Here's what my non-acpi/apic system (486@133MHz) says:
>kern.clockrate: { hz = 1000, tick = 1000, profhz = 1024, stathz = 128 }
>And here from my 1GHz Celeron with acpi and apic:
>kern.clockrate: { hz = 1000, tick = 1000, profhz = 666, stathz = 133 }
>
>Can somebody eplain the profhz to me? Especially why it's higher on the
>much slower machine...
On your older system, profhz and stathz are driven the RTC interrupts
and tick is driven by the 8254. On your newer system all the clocks
are derived from the LAPIC timer running at 2000Hz - tick is LAPIC/2,
profhz is LAPIC/3 and stathz is LAPIC/15.
The actual values of profhz and stathz are unimportant, their primary
purpose is to sample the system state at a rate that is difficult for
processes to synchronize with. If a process synchronizes with the
profiling/statistics clock then the statistics become unreliable (and
a process can cheat the scheduler by appearing to use no CPU time).
--
Peter Jeremy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050904192858.GB77285>