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 <pbonz...@redhat.com> >> --- >> 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 > > >