qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] linux-aio: keep processing events if MAX_EVENTS


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH] linux-aio: keep processing events if MAX_EVENTS reached
Date: Tue, 28 Jun 2016 10:25:32 +0100
User-agent: Mutt/1.6.1 (2016-04-27)

On Mon, Jun 27, 2016 at 06:42:33PM +0200, Paolo Bonzini wrote:
> 
> 
> On 27/06/2016 18:37, Stefan Hajnoczi wrote:
> > Commit ccb9dc10129954d0bcd7814298ed445e684d5a2a ("linux-aio: Cancel BH
> > if not needed") exposed a side-effect of scheduling the BH for nested
> > event loops.  When io_getevents(2) fetches MAX_EVENTS events then it's
> > necessary to call it again.  Failure to do so can lead to hung I/O
> > because the eventfd has already been cleared and the completion BH will
> > not run again.
> > 
> > This patch fixes the hang by calling io_getevents(2) again if the events
> > array was totally full.
> > 
> > Reported-by: Roman Penyaev <address@hidden>
> > Signed-off-by: Stefan Hajnoczi <address@hidden>
> > ---
> >  block/linux-aio.c | 5 +++++
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/block/linux-aio.c b/block/linux-aio.c
> > index e468960..af15f85 100644
> > --- a/block/linux-aio.c
> > +++ b/block/linux-aio.c
> > @@ -117,6 +117,7 @@ static void qemu_laio_completion_bh(void *opaque)
> >      LinuxAioState *s = opaque;
> >  
> >      /* Fetch more completion events when empty */
> > +more_events:
> >      if (s->event_idx == s->event_max) {
> >          do {
> >              struct timespec ts = { 0 };
> > @@ -146,6 +147,10 @@ static void qemu_laio_completion_bh(void *opaque)
> >          qemu_laio_process_completion(laiocb);
> >      }
> >  
> > +    if (s->event_idx == MAX_EVENTS) {
> > +        goto more_events; /* there might still be events waiting for us */
> > +    }
> > +
> >      if (!s->io_q.plugged && !QSIMPLEQ_EMPTY(&s->io_q.pending)) {
> >          ioq_submit(s);
> >      }
> > 
> 
> Do we want to do it after submitting, in order to reduce latency and
> perhaps even get some results immediately?

No, if more I/O requests are submitted let the event loop spin to avoid
starving the event loop when there is a high IOPS device.

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]