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
