Bug #1389
closedlockless acpi-safe/acpi-safe24
0%
Description
Hi,
Following patch git rid of the clock spinlock used in acpi-safe/acpi-safe24:
http://leaf.dragonflybsd.org/~sephe/0001-acpi-timer-Percpu-last_count-and-time_base-mai.patch
Please test/review. I have tested the patch w/ acpi-safe24.
Best Regards,
sephe
Updated by sepherosa over 15 years ago
Drop, reference
http://leaf.dragonflybsd.org/mailarchive/submit/2009-05/msg00019.html
Matt also suggested:
if (check_base)
spinlock
if (check_base)
..
spinunlock
But since count will also need to be updated, this probably will not work either.
Updated by dillon over 15 years ago
:Hi,
:
:Following patch git rid of the clock spinlock used in acpi-safe/acpi-safe24:
:http://leaf.dragonflybsd.org/~sephe/0001-acpi-timer-Percpu-last_count-and-time_base-mai.patch
:
:Please test/review. I have tested the patch w/ acpi-safe24.
:
:Best Regards,
:sephe
I think we might still need the critical section to avoid
interrupt races. If acpi_timer_get_timecount24() and friends
are re-entered by an interrupt we could end up with
acpi_timer_base[cpu] getting bumped twice.
We could probably avoid the critical section by having an
interlock count to prevent the reentered call in the
interrupt from bumping acpi_timer_base[], but critical
sections are so cheap on DFly we might as well just
use a critical section.
I am also a bit worried about the acpi_timer_base[] for individual
cpu's getting out of sync with each other and creating a real
mess. e.g. if a cpu is stopped by the debugger or otherwise does
not refresh the base by polling the counter.
Finally we might also want to change those static array declarations
to an array of structure for acpi_timer_base and acpi_last_counter,
and cache-aligning the elements.
I think the getting-out-of-sync problem between the cpus could be
a show-stopper, though.
-Matt
Matthew Dillon
<dillon@backplane.com>