qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 02/12] qemu-thread: add QemuEvent


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 02/12] qemu-thread: add QemuEvent
Date: Thu, 16 May 2013 12:49:20 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4

Il 16/05/2013 12:15, Stefan Hajnoczi ha scritto:
> On Wed, May 15, 2013 at 05:48:47PM +0200, Paolo Bonzini wrote:
>> This emulates Win32 manual-reset events using futexes or conditional
>> variables.  Typical ways to use them are with multi-producer,
>> single-consumer data structures, to test for a complex condition whose
>> elements come from different threads:
>>
>>     for (;;) {
>>         qemu_event_reset(ev);
>>         ... test complex condition ...
>>         if (condition is true) {
>>             break;
>>         }
>>         qemu_event_wait(ev);
>>     }
>>
>> Alternatively:
>>
>>     ... compute condition ...
>>     if (condition) {
>>         do {
>>             qemu_event_wait(ev);
>>             qemu_event_reset(ev);
>>             ... compute condition ...
>>         } while(condition);
>>         qemu_event_set(ev);
>>     }
>>
>> QemuEvent provides a very fast userspace path in the common case when
>> no other thread is waiting, or the event is not changing state.  It
>> is used to report RCU quiescent states to the thread calling
>> synchronize_rcu (the latter being the single consumer), and to report
>> call_rcu invocations to the thread that receives them.
> 
> It would be nice to describe the need for the Linux futex code.  pthread
> mutex/condvars are implemented in terms of futexes already, so how much
> benefit is there - I thought they stay in userspace in the non-contended
> case too?

Yes, but they are still measurably slower, around 20%.  I don't have
around the program I wrote for QemuEvent, because I did the measurement
~2 years ago.  However, here is one that tests a similar synchronization
primitive (not exactly the same as QemuEvent).  You can run it like this:

$ ./a.out -c 100 10 4 40 # with mutex/condvar
4 child processes, avg think time 100 msec
Avg event distance 10 msec. Running for 40 sec
........................................
waits            1404   0.663 us (fast)
  slow waits     152
signal           3890   0.784 us
  fast path      0                             <<<< (this is bogus)

$ ./a.out 100 10 4 40 # with futex
4 child processes, avg think time 100 msec
Avg event distance 10 msec. Running for 40 sec
........................................
waits            1383   0.635 us (fast)
  slow waits     147
signal           3924   0.640 us
  fast path      3791


Paolo

Attachment: evc.c
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]