On Mon, Sep 30, 2013 at 9:34 AM, Alex Bligh <a...@alex.org.uk> wrote: >>> > 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, thanks for the link - Mike