qemu-devel
[Top][All Lists]
Advanced

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

Attachment: signature.asc
Description: PGP signature


reply via email to

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