On Tue, Apr 29, 2008 at 07:22:53PM -0500, Anthony Liguori wrote: > Marcelo Tosatti wrote: > >True. > > > >Either way, this starvation due to signals can't happen with the current > >scheme because signals are blocked. It seems a significant drawback. > > > > Practically speaking, I don't see signal starving being a problem. Part > of the benefit of this approach is that we're reducing the overall > number of signals received. With the in-kernel PIT, the number of > userspace signals is even further reduced. > > >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. > 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. 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
