From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53934) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLe4o-0006td-1x for qemu-devel@nongnu.org; Wed, 11 Feb 2015 15:40:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YLe4f-000344-8S for qemu-devel@nongnu.org; Wed, 11 Feb 2015 15:40:02 -0500 Received: from mail-we0-x22f.google.com ([2a00:1450:400c:c03::22f]:58850) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLe4e-000340-SX for qemu-devel@nongnu.org; Wed, 11 Feb 2015 15:39:53 -0500 Received: by mail-we0-f175.google.com with SMTP id x3so5954751wes.6 for ; Wed, 11 Feb 2015 12:39:52 -0800 (PST) Sender: Paolo Bonzini Message-ID: <54DBBE13.9010100@redhat.com> Date: Wed, 11 Feb 2015 21:39:47 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1423674872-10676-1-git-send-email-pbonzini@redhat.com> <1423674872-10676-3-git-send-email-pbonzini@redhat.com> <20150211202649.3809.84600@loki> In-Reply-To: <20150211202649.3809.84600@loki> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/3] rcu: run RCU callbacks under the BQL List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Roth , qemu-devel@nongnu.org On 11/02/2015 21:26, Michael Roth wrote: > Quoting Paolo Bonzini (2015-02-11 11:14:31) >> This needs to go away sooner or later, but one complication is the >> complex VFIO data structures that are modified in instance_finalize. >> Take a shortcut for now. >> >> Signed-off-by: Paolo Bonzini >> --- >> tests/Makefile | 2 +- >> util/rcu.c | 5 +++++ >> 2 files changed, 6 insertions(+), 1 deletion(-) >> >> diff --git a/tests/Makefile b/tests/Makefile >> index d5df168..e11bfe7 100644 >> --- a/tests/Makefile >> +++ b/tests/Makefile >> @@ -257,7 +257,7 @@ tests/test-x86-cpuid$(EXESUF): tests/test-x86-cpuid.o >> tests/test-xbzrle$(EXESUF): tests/test-xbzrle.o migration/xbzrle.o page_cache.o libqemuutil.a >> tests/test-cutils$(EXESUF): tests/test-cutils.o util/cutils.o >> tests/test-int128$(EXESUF): tests/test-int128.o >> -tests/rcutorture$(EXESUF): tests/rcutorture.o libqemuutil.a >> +tests/rcutorture$(EXESUF): tests/rcutorture.o libqemuutil.a libqemustub.a >> >> tests/test-qdev-global-props$(EXESUF): tests/test-qdev-global-props.o \ >> hw/core/qdev.o hw/core/qdev-properties.o hw/core/hotplug.o\ >> diff --git a/util/rcu.c b/util/rcu.c >> index 486d7b6..bd73b8e 100644 >> --- a/util/rcu.c >> +++ b/util/rcu.c >> @@ -35,6 +35,7 @@ >> #include "qemu/rcu.h" >> #include "qemu/atomic.h" >> #include "qemu/thread.h" >> +#include "qemu/main-loop.h" >> >> /* >> * Global grace period counter. Bit 0 is always one in rcu_gp_ctr. >> @@ -237,20 +238,24 @@ static void *call_rcu_thread(void *opaque) >> >> atomic_sub(&rcu_call_count, n); >> synchronize_rcu(); >> + qemu_mutex_lock_iothread(); >> while (n > 0) { >> node = try_dequeue(); >> while (!node) { >> + qemu_mutex_unlock_iothread(); >> qemu_event_reset(&rcu_call_ready_event); >> node = try_dequeue(); >> if (!node) { >> qemu_event_wait(&rcu_call_ready_event); >> node = try_dequeue(); >> } >> + qemu_mutex_lock_iothread(); >> } >> >> n--; >> node->func(node); > > Not sure I understand the reasoning for lock/unlock beyond just guarding > the ->func() call, what else are we serializing? I'm trying to avoid multiple back-to-back unlocks and locks. Being coarse-grained qemu_mutex_lock_iothread/qemu_mutex_unlock_iothread is likely to hit the slow path---and also slow down _other_ threads. Paolo >> } >> + qemu_mutex_unlock_iothread(); >> } >> abort(); >> } >> -- >> 1.8.3.1 > > >