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

Avi Kivity
2008-04-16T08:37:00Z

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.

--
error compiling committee.c: too many arguments to function