Am 10.05.2016 um 11:30 hat Stefan Hajnoczi geschrieben: > On Mon, May 09, 2016 at 06:31:44PM +0200, Paolo Bonzini wrote: > > On 19/04/2016 11:09, Stefan Hajnoczi wrote: > > >> > This has better performance because it executes fewer system calls > > >> > and does not use a bottom half per disk. > > > Each aio_context_t is initialized for 128 in-flight requests in > > > laio_init(). > > > > > > Will it be possible to hit the limit now that all drives share the same > > > aio_context_t? > > > > It was also possible before, because the virtqueue can be bigger than > > 128 items; that's why there is logic to submit I/O requests after an > > io_get_events. As usual when the answer seems trivial, am I > > misunderstanding your question? > > I'm concerned about a performance regression rather than correctness. > > But looking at linux-aio.c there *is* a correctness problem: > > static void ioq_submit(struct qemu_laio_state *s) > { > int ret, len; > struct qemu_laiocb *aiocb; > struct iocb *iocbs[MAX_QUEUED_IO]; > QSIMPLEQ_HEAD(, qemu_laiocb) completed; > > do { > len = 0; > QSIMPLEQ_FOREACH(aiocb, &s->io_q.pending, next) { > iocbs[len++] = &aiocb->iocb; > if (len == MAX_QUEUED_IO) { > break; > } > } > > ret = io_submit(s->ctx, len, iocbs); > if (ret == -EAGAIN) { > break; > } > if (ret < 0) { > abort(); > } > > s->io_q.n -= ret; > aiocb = container_of(iocbs[ret - 1], struct qemu_laiocb, iocb); > QSIMPLEQ_SPLIT_AFTER(&s->io_q.pending, aiocb, next, &completed); > } while (ret == len && !QSIMPLEQ_EMPTY(&s->io_q.pending)); > s->io_q.blocked = (s->io_q.n > 0); > } > > io_submit() may have submitted some of the requests when -EAGAIN is > returned. QEMU gets no indication of which requests were submitted.
My understanding (which is based on the manpage rather than code) is that -EAGAIN is only returned if no request could be submitted. In other cases, the number of submitted requests is returned (similar to how short reads work). > It may be possible to dig around in the s->ctx rings to find out or we > need to keep track of the number of in-flight requests so we can > prevent ever hitting EAGAIN. > > ioq_submit() pretends that no requests were submitted on -EAGAIN and > will submit them again next time. This could result in double > completions. Did you check in the code that this can happen? > Regarding performance, I'm thinking about a guest with 8 disks (queue > depth 32). The worst case is when the guest submits 32 requests at once > but the Linux AIO event limit has already been reached. Then the disk > is starved until other disks' requests complete. Sounds like a valid concern. Kevin
pgpQ3PKjQfaHS.pgp
Description: PGP signature