Re: [Qemu-devel] [PATCH 2/3] rcu: run RCU callbacks under the BQL

[Paolo Bonzini]

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
> 
> 
>