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

[Paolo Bonzini <pbonzini@redhat.com>]

Il 05/04/2012 15:00, Jan Kiszka ha scritto:
>> > But QemuEvent takes away the best name for a useful concept (a
>> > cross-platform implementation of Win32 events; you can see that in the
> The concept is not lost, it perfectly fit this incarnation. Just the
> special futex version for Linux is not feasible.

It's not just about the futex version.  Can you implement a
userspace-only fast path?  Perhaps with EFD_SEMAPHORE you can:

  x = state of the event
    bit 0 = set/reset
    bit 1..31 = waiters

  set
    y = xchg(&x, 1)
    if y > 1
      write y >> 1 to eventfd

  wait
    do {
      y = x
      if (y & 1) return;
    } while (fail to cmpxchg x from y to y + 2)
    read from eventfd

  reset
    cmpxchg x from 1 to 0

but what if you are falling back to pipes?

2) It's much more heavyweight since (like Windows primitives) you need
to set aside OS resources for each QemuEvent.  With mutexes and condvars
the kernel-side waitqueues come and go as they are used.

>> > 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.

Paolo