HPET vs other timers

Kris Kennaway kris at obsecurity.org
Sun May 20 22:37:28 UTC 2007


I recently noticed that the default timecounter on my system has
changed to HPET (formerly it used ACPI-fast by default):

kern.timecounter.choice: TSC(800) ACPI-fast(1000) HPET(2000) i8254(0) dummy(-1000000)OA

This is of particular interest to me because the timecounter speed and
serialization requirements are the major performance factor for things
like LOCK_PROFILING (in the default configuration this inserts at
least one time counter read into every kernel lock operation).  This
is an interesting test because time counters that require some kind of
explicit or implicit serialization tend to serialize all lock
operations and dramatically reduce performance.  In addition there may
be different overheads to timecounter reads.

The following is a comparison of a multiprocessor benchmark (it is not
important what it is, except that "higher is better") performance on
an 8-core system with LOCK_PROFILING active:

no LOCK_PROFILING	24559.36 (baseline)
TSC			19627.16
ACPI-fast		4633.02
HPET			2917.85
i8254			panic :( [1]

i.e. HPET is actually slower than all the other (working ;)
timecounters in this configuration.

Can you provide some more justification of why HPET has the highest
quality factor and is appropriate to be used as the preferred


[1] Fatal double fault
cpuid = 1; apic id = 01
panic: double fault
cpuid = 1
KDB: enter: panic
NMI ... going to debugger
[thread pid 847 tid 100163 ]
Stopped at      lapic_ipi_raw:  pushq   %rbp
db> wh
Tracing pid 847 tid 100163 td 0xffffff008c02f000
lapic_ipi_raw() at lapic_ipi_raw
dmapbase() at 0xffffff008c02f000
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20070520/6dacd3b1/attachment.pgp

More information about the freebsd-current mailing list