[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
evc.c
Description: Text Data
- [Qemu-devel] [RFC PATCH 00/12] RCU implementation for QEMU, Paolo Bonzini, 2013/05/15
- [Qemu-devel] [PATCH 02/12] qemu-thread: add QemuEvent, Paolo Bonzini, 2013/05/15
- [Qemu-devel] [PATCH 03/12] rcu: add rcu library, Paolo Bonzini, 2013/05/15
- [Qemu-devel] [PATCH 04/12] qemu-thread: register threads with RCU, Paolo Bonzini, 2013/05/15
- [Qemu-devel] [PATCH 05/12] rcu: add call_rcu, Paolo Bonzini, 2013/05/15
- [Qemu-devel] [PATCH 06/12] rcu: add rcutorture, Paolo Bonzini, 2013/05/15
- [Qemu-devel] [PATCH 09/12] event loop: report RCU quiescent states, Paolo Bonzini, 2013/05/15
- [Qemu-devel] [PATCH 08/12] qemu-thread: report RCU quiescent states, Paolo Bonzini, 2013/05/15