Re: [Qemu-devel] Using aio_poll for timer carrier threads

[Paolo Bonzini <pbonzini@redhat.com>]

Il 19/08/2013 15:40, Jan Kiszka ha scritto:
> On 2013-08-19 15:21, Paolo Bonzini wrote:
>> Il 13/08/2013 16:54, Jan Kiszka ha scritto:
>>>>> Using an AioContext lock for timers is somewhat complicated for lock
>>>>> ordering, because context A could try to modify a timer from context B,
>>>>> at the same time when context B is modifying a timer from context A.
>>>>> This would cause a deadlock.
>>> That's like MMIO access on device A triggers MMIO access on B and vice
>>> versa - why should we need this, so why should we support this? I think
>>> the typical case is that timers (and their lists) and data structures
>>> they access have a fairly close relation, thus can reuse the same lock.
>>
>> Yes, that's true.  Still it would have to be documented, and using
>> too-coarse locks risks having many BQLs, which multiplies the complexity
>> (fine-grained locking at least keeps critical sections small and limits
>> the amount of nested locking).
> 
> As this lock does not require taking other locks while holding it, it
> should actually be fine.

Using an AioContext lock would be more dangerous, though.  The risk is
mostly that someone is holding _another_ AioContext lock while calling a
timer function.

For MMIO, the rule would be that all address_space_rw/map/unmap must be
done with no lock taken.

>> I like Stefan's patches to make the timer list thread-safe, especially
>> if we can optimize it (with RCU?) to make the read side lockless.
> 
> What is a pure read-side in that context? Checks if some timer is
> expired?

Yes.  It is actually quite common, as Stefan pointed out elsewhere to
Ping Fan, as it happens at least once in each iteration of the loop.

The read side doesn't really need to look beyond the head of the list.

> Given that RCU write sides are heavier than plain mutexes and
> many typical accesses (mod, del, expire) involve writing, such an
> optimization may also be counterproductive.

This would have to be a creative use of RCU, with no "copy" in it...
basically you can use RCU only as a substitute for reference counting.
call_rcu/synchronize_rcu is not done on every write operation, all we
need to do is ensuring that devices free timers only after an RCU
critical section.  We should do the same for memory regions, see my
patches to split exitfn and instance_finalize; I'll go more in depth in
my KVM Forum 2013.

Lockless algorithms (including RCU) are somewhat appealing because you
do not have to worry about locking, but of course all warnings about
increased complexity and premature optimization apply.

Paolo