[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [Qemu-devel] Block layer complexity: what to do to keep
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-block] [Qemu-devel] Block layer complexity: what to do to keep it under control? |
Date: |
Thu, 30 Nov 2017 14:19:54 +0000 |
User-agent: |
Mutt/1.9.1 (2017-09-22) |
On Thu, Nov 30, 2017 at 05:47:09PM +0800, Fam Zheng wrote:
> On Wed, 11/29 12:00, Stefan Hajnoczi wrote:
> > On Wed, Nov 29, 2017 at 11:55:02AM +0800, Fam Zheng wrote:
> >
> > Event loops and coroutines are good but they should not be used directly
> > by block drivers and block jobs. We need safe, high-level APIs that
> > implement commonly-used operations.
> >
> > > - Documentation
> > >
> > > There is no central developer doc about block layer, especially how all
> > > pieces
> > > fit together. Having one will make it a lot easier for new contributors
> > > to
> > > understand better. Of course, we're facing the old problem: the code is
> > > moving, maintaining an updated document needs effort.
> > >
> > > Idea: add ./doc/deve/block.txt?
> >
> > IOThreads and AioContexts are addressed here:
> > docs/devel/multiple-iothreads.txt
> >
> > The game has become significantly more complex than what the document
> > describes. It's lacking aio_co_wake() and aio_co_schedule() for
> > example.
> >
> > > - Simplified code, or more orthogonal/modularized architecture.
> > >
> > > Each aspect of block layer is complex enough so isolating them as much
> > > as
> > > possible is a reasonable approach to control the complexity. Block jobs
> > > and
> > > throttling becoming block filters is a good example, we should identify
> > > more.
> > >
> > > Idea: rethink event loops. Create coroutines ubiquitously (for example
> > > for
> > > each fd handler, BH and timer), so that many nested aio_poll() can be
> > > removed.
> > >
> > > Crazy idea: move the whole block layer to a vhost process, and implement
> > > existing features differently, especially in terms of multi-threading
> > > (hint:
> > > rust?).
> >
> > A reimplementation will not solve the problem because:
> >
> > 1. If it still has the same feature set and requirements then the level
> > of complexity will be comparable.
> >
> > 2. We can reduce accidental (inessential) complexity by continuing the
> > various efforts around the block graph, block jobs, multi-queue block
> > layer with an eye towards higher level APIs.
>
> Starting over is certainly not the motivation to do qemu-vhost, but it would
> be
> an opportunity to use different async/concurrency paradigms if that is going
> to
> happen. I think in current block layer, event loop + coroutine is a good
> combination, but having nested aio_poll()'s made it worse, then mixing
> IOThreads
> in makes it a lot more complicated.
Why alternative model are you thinking of?
One slight change is to make everything run in a coroutine so that there
are no while (aio_poll()) loops. Instead the caller would yield.
But the fundamental problem remains that drain is necessary and the
storage stack does not support request cancellation. For example, when
the virtio-blk-pci device is reset QEMU has no way of (safely)
cancelling requests so it has to wait for all requests to complete.
This means we're stuck with synchronization points.
I agree that adding threading makes thing more complicated but
ultimately there is a real requirement to do that. It's like the
difference between a simple block driver that is designed only for
qemu-img convert versus a fully-featured block driver that supports
parallel I/O. The complexity is much higher but you can't wish it away
if you want parallel I/O.
Stefan
signature.asc
Description: PGP signature