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. 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
