From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: [PATCH][RFC] Use pipe() to simulate signalfd() Date: Tue, 29 Apr 2008 23:16:42 -0300 Message-ID: <20080430021642.GA19374@dmt> References: <20080429223706.GA18006@dmt> <4817A46B.7000302@us.ibm.com> <20080429231313.GA18231@dmt> <4817AC2E.60909@us.ibm.com> <20080429233717.GA18425@dmt> <4817B2DD.7030100@us.ibm.com> <20080430000829.GA18682@dmt> <4817BBDD.4020505@us.ibm.com> <20080430003801.GB18682@dmt> <4817C1BA.70107@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel@lists.sourceforge.net, Avi Kivity To: Anthony Liguori Return-path: Content-Disposition: inline In-Reply-To: <4817C1BA.70107@us.ibm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces@lists.sourceforge.net Errors-To: kvm-devel-bounces@lists.sourceforge.net List-Id: kvm.vger.kernel.org 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