Re: [Qemu-devel] [PATCH 0/5] Spread the use of QEMU threading & locking API

[Paolo Bonzini <pbonzini@redhat.com>]

Il 05/04/2012 16:01, Jan Kiszka ha scritto:
> Either you signal via the fd or via a variable. Doing both won't work as
> the state can only be in the eventfd/pipe (for external triggers). We
> could switch the mode of our QemuEvent on init, but that will become
> ugly I'm afraid.

Yeah...

>>>>> RCU patches which were even posted on the list).  We already have a
>>>>> perfectly good name for EventNotifiers, and there's no reason to break
>>>>> the history of event-notifier.c.
>>> Have you measured if the futex optimization is actually worth the
>>> effort, specifically compared to the fast path of mutex/cond loop?
>>
>> A futex is 30% faster than the mutex/cond combination.  It's called on
>> fast paths (call_rcu and, depending on how you implement RCU,
>> rcu_read_unlock) so it's important.
> 
> If RCU is the only user for this optimized signaling, then I would vote
> for doing it in the RCU layer directly. If there are also other users in
> sight that could benefit (because of mostly-set-rarely-reset patterns),
> I agree that a QemuEvent is the better home. Can you name more use cases
> in QEMU?

No idea, but the general use case is when you have something that is
multi-producer and single-consumer.

Paolo