Re: [PATCH][RFC] Use pipe() to simulate signalfd()

[Marcelo Tosatti <mtosatti@redhat.com>]

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