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 _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
