On Tue, Apr 29, 2008 at 07:47:54PM -0500, Anthony Liguori wrote: > Marcelo Tosatti wrote: > >>>Moving the signal handling + pipe write to a separate thread should get > >>>rid of it. > >>> > >>> > >>Yeah, but then you just introduce buffering problems since if you're > >>getting that many signals, the pipe will get full. > >> > > > >It is OK to lose signals if you have at least one queued in the pipe. > > > > If you're getting so many signals that you can't make forward progress > on any system call, you're application is not going to function > anymore. A use of signals in this manner is broken by design. > > >>No point in designing for something that isn't likely to happen in > >>practice. > >> > > > >You should not design something making the assumption that this scenario > >won't happen. > > > >For example this could happen in high throughput guests using POSIX AIO, > >actually pretty likely to happen if data is cached in hosts pagecache. > > > > We really just need to move away from signals as best as we can. I've > got a patch started that implements a thread-pool based AIO mechanism > for QEMU. Notifications are done over a pipe so we don't have to deal > with the unreliability of signals. > > I can't imagine a guest trying to do so much IO though that this would > really ever happen. POSIX AIO can only have one outstanding request > per-fd. To complete the IO request, you would have to eventually go > back to the guest and during that time, the IO thread is going to be > able to make forward progress.
No. POSIX AIO can have one _in flight_ AIO per-fd, but many pending AIO requests per-fd. You don't have to go back to guest mode to get more AIO completions. And then you have drivers arming timers. I just don't like the idea. > You won't get a signal again until a new IO request is submitted. > > Regards, > > Anthony Liguori > > >Its somewhat similar to what happens with NAPI and interrupt mitigation. > > > > ------------------------------------------------------------------------- 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
