Re: [patch 2/2] QEMU: decrease console "refresh rate" with -nographic

Anthony Liguori
2008-04-16T13:53:25Z

Avi Kivity wrote:
> Anthony Liguori wrote:
>>>
>>> What about aio completions? The only race-free way to handle both
>>> posix aio completion and fd readiness is signals AFAIK.
>>
>> We poll aio completion after the select don't we? Worst case
>> scenario we miss a signal and wait to poll after the next select
>> event. That's going to occur very often because of the timer.
>
> if select() doesn't enable signals (like you can do with pselect) you
> may sit for a long time in select() until the timer expires.
>
> Consider a 100Hz Linux guest running 'ls -lR' out of a cold cache:
> instead of 1-2 ms disk latencies you'll see 10 ms latencies, killing
> performance by a factor of 5.
>
> I see the following possible solutions:
>
> 1. Apply Anders' patch and keep I/O completions signal based.
>
> 2. Use signalfd() to convert aio completions to fd readiness,
> emulating signalfd() using a thread which does sigwait()+write() (to a
> pipe) on older hosts
>
> 3. Use a separate thread for aio completions
>
> 4. Use pselect(), live with the race on older hosts (it was introduced
> in 2.6.16, which we barely support anyway), live with the signal
> delivery inefficiency.
>
> When I started writing this email I was in favor of (1), but now with
> the new signalfd emulation I'm leaning towards (2). I still think (1)
> should be merged, preferably to qemu upstream.

There is a 5th option. Do away with the use of posix aio. We get
absolutely no benefit from it because it's limited to a single thread.
Fabrice has reverted a patch to change that in the past.

Regards,

Anthony Liguori