[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 2/3] rcu: run RCU callbacks under the BQL
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH 2/3] rcu: run RCU callbacks under the BQL |
Date: |
Wed, 11 Feb 2015 21:39:47 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 |
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 <address@hidden>
>> ---
>> 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
>
>
>