Mike,
> void qemu_clock_notify(QEMUClockType type)
...
> int64_t qemu_clock_deadline_ns_all(QEMUClockType type)
...
> I think these functions are always called now with the BQL held, so I
> wonder if they are good candidates for RCU?
These routines iterate through the list of timerlists held by
a clock.
They do not iterate through the list of active timers in a timer
list. I believe the latter is what active_timers_lock protects.
The list of timers attached to a clock is only modified when timers
are created and deleted which is (currently) under the BQL.
Sorry, and thanks for the correction re: active_timers_lock. I should
have said that clock->timerlists may need its own mutex if and when we
remove the BQL from the timer code.
Correct. The list of timerlists is only modified when a
QEMUTimerListGroup is created or destroyed (currently when an
AioContext is created or destroyed), and that is done with the
BQL held.
As you point out, it's currently walked by a couple of functions
that also have the BQL held.
I think the most likely change here is that the walkers might
move outside the BQL. Given modification of this list is so rare,
the lock would be very very read heavy, so RCU is probably a
sensible option.
This link may (or may not) help in understanding:
http://blog.alex.org.uk/2013/08/24/changes-to-qemus-timer-system/
--
Alex Bligh
