On Mon, Sep 30, 2013 at 9:34 AM, Alex Bligh <
address@hidden> 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