qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 0/3] Make thread pool implementation modular


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH v2 0/3] Make thread pool implementation modular
Date: Mon, 11 Nov 2013 13:43:29 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Mon, Nov 11, 2013 at 11:00:45AM +0100, Matthias Brugger wrote:
> 2013/11/5 Stefan Hajnoczi <address@hidden>:
> > I'd also like to see the thread pool implementation you wish to add
> > before we add a layer of indirection which has no users yet.
> 
> Fair enough, I will evaluate if it will make more sense to implement a
> new AIO infrastructure instead to try reuse the thread-pool.
> Actually my implementation will differ in the way, that we will have
> several workerthreads with everyone of them having its own queue. The
> requests will be distributed between them depending on an identifier.
> The request function which  the worker_thread call will be the same as
> using aio=threads, so I'm not quite sure which will be the way to go.
> Any opinions and hints, like the one you gave are highly appreciated.

If I understand the slides you linked to correctly, the guest will pass
an identifier with each request.  The host has worker threads allowing
each stream of requests to be serviced independently.  The idea is to
associate guest processes with unique identifiers.

The guest I/O scheduler is supposed to submit requests in a way that
meets certain policies (e.g. fairness between processes, deadlines,
etc).

Why is it necessary to push this task down into the host?  I don't
understand the advantage of this approach except that maybe it works
around certain misconfigurations, I/O scheduler quirks, or plain old
bugs - all of which should be investigated and fixed at the source
instead of adding another layer of code to mask them.

Stefan



reply via email to

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