From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46112) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFnQ3-0003Jp-Lq for qemu-devel@nongnu.org; Thu, 05 Apr 2012 10:12:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SFnPw-0008Ff-T2 for qemu-devel@nongnu.org; Thu, 05 Apr 2012 10:12:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:18335) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFnPw-0008Cr-L3 for qemu-devel@nongnu.org; Thu, 05 Apr 2012 10:12:04 -0400 Message-ID: <4F7DA821.1030409@redhat.com> Date: Thu, 05 Apr 2012 16:11:45 +0200 From: Paolo Bonzini 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> <4F7DA5AA.8070100@siemens.com> In-Reply-To: <4F7DA5AA.8070100@siemens.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: Jan Kiszka Cc: Kevin Wolf , Anthony Liguori , "qemu-devel@nongnu.org" 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