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

[Avi Kivity <avi@qumranet.com>]

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


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone