On 29.07.2012 11:37, Bruce Evans wrote:
On Sun, 29 Jul 2012, Alexander Motin wrote:
With ACPI timer gradually becoming one of slowest in the system, is
there some reason to use it directly in acpi_cpu_idle()? I've made a
to use binuptime() instead. Using even HPET from system time counter
(not even speaking about TSC) that significantly improves performance
on some workloads if this code is not covered by MWAIT optimization in
Does it work with a perverse timecounter like the i8254 work?
At least on my test system it does, even though predictably much slower
then the others.
user is permitted to switch to any supported timecounter. There are
other perverse ones:
- ACPI. This seems to be unavailable if the system thinks ACPI-fast
works. Bug. The user should be able to downgrade to it if ACPI-fast
in fact doesn't work. Since it reads the hardware more than once,
it is much slower than direct use of the hardware.
- ACPI-fast. Even this is perverse. It only reads the hardware once,
but goes through many software layers.
binuptime() is more accurate than uncalibrated scaling. Is accuracy
Accuracy is not required at all. +-20% is not a problem.
If not, the CPU ticker might work, and is faster than HPET,
and and is not under user control for perverse settings. It normally
reduces to readtsc() with no serializing instruction even in proposed
changes. This is good enough for process times (not very good) and
depends on the CPU not changing. Its calibration is very accurate
(similar to timecounters) modulo bugs, but not always up to date.
Problem with ticker that it may stop during idle periods, and idle is
exactly what happens here. Unlike timecounter usage here we don't need
CPU synchronicity, but we need it working during deep sleeps.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"