From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47839) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFnFl-0007Xa-0H for qemu-devel@nongnu.org; Thu, 05 Apr 2012 10:01:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SFnFY-0005jP-0f for qemu-devel@nongnu.org; Thu, 05 Apr 2012 10:01:31 -0400 Received: from thoth.sbs.de ([192.35.17.2]:22838) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFnFX-0005it-MU for qemu-devel@nongnu.org; Thu, 05 Apr 2012 10:01:19 -0400 Message-ID: <4F7DA5AA.8070100@siemens.com> Date: Thu, 05 Apr 2012 16:01:14 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4F7C663E.20200@redhat.com> <4F7C67BA.4000007@siemens.com> <4F7C68E2.508@redhat.com> <4F7C715E.506@siemens.com> <4F7C7928.1070404@redhat.com> <4F7C7D11.3040302@siemens.com> <4F7C82B8.8090602@siemens.com> <4F7D4F1C.3070208@redhat.com> <4F7D7A0C.9010600@siemens.com> <4F7D7D0E.4080309@redhat.com> <4F7D7F9D.5080805@siemens.com> <4F7D8227.4050108@redhat.com> <4F7D8A32.5050401@siemens.com> <4F7D94A8.8040107@redhat.com> <4F7D977A.1020905@siemens.com> <4F7DA0C0.1060209@redhat.com> In-Reply-To: <4F7DA0C0.1060209@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/5] Spread the use of QEMU threading & locking API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Kevin Wolf , Anthony Liguori , "qemu-devel@nongnu.org" On 2012-04-05 15:40, Paolo Bonzini wrote: > 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? 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. > > 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. 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? Happy vacations, Jan (off for Easter now) -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux