[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] QEMU event loop optimizations
From: |
Sergio Lopez |
Subject: |
Re: [Qemu-devel] QEMU event loop optimizations |
Date: |
Fri, 05 Apr 2019 18:33:18 +0200 |
User-agent: |
mu4e 1.0; emacs 26.1 |
Paolo Bonzini writes:
> On 26/03/19 14:18, Stefan Hajnoczi wrote:
>> Hi Sergio,
>> Here are the forgotten event loop optimizations I mentioned:
>>
>> https://github.com/stefanha/qemu/commits/event-loop-optimizations
>>
>> The goal was to eliminate or reorder syscalls so that useful work (like
>> executing BHs) occurs as soon as possible after an event is detected.
>>
>> I remember that these optimizations only shave off a handful of
>> microseconds, so they aren't a huge win. They do become attractive on
>> fast SSDs with <10us read/write latency.
>>
>> These optimizations are aggressive and there is a possibility of
>> introducing regressions.
>>
>> If you have time to pick up this work, try benchmarking each commit
>> individually so performance changes are attributed individually.
>> There's no need to send them together in a single patch series, the
>> changes are quite independent.
>
> I reviewed the patches now:
>
> - qemu_bh_schedule_nested should not be necessary since we have
> ctx->notify_me to also avoid the event_notifier_set call. However, it
> is possible to avoid the smp_mb at the beginning of aio_notify, since
> atomic_xchg already implies it. Maybe add a "static void
> aio_notify__after_smp_mb"?
try_poll_mode() is called with ctx->notify_me != 0, so we get at least
one event_notifier_set() call while working in polling mode.
Sergio.
signature.asc
Description: PGP signature