Hello, 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 timecounter? Kris [1] Fatal double fault cpuid = 1; apic id = 01 panic: double fault cpuid = 1 KDB: enter: panic NMI ISA 20, EISA ff 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
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:10 UTC