Re: [RFC] thread-pool: Add option to fix the pool size

[Kevin Wolf]

Am 14.02.2022 um 14:10 hat Stefan Hajnoczi geschrieben:
> On Mon, Feb 14, 2022 at 12:38:22PM +0100, Kevin Wolf wrote:
> > Am 14.02.2022 um 11:09 hat Stefan Hajnoczi geschrieben:
> > > On Fri, Feb 11, 2022 at 12:32:57PM +0100, Kevin Wolf wrote:
> > > > Am 03.02.2022 um 15:19 hat Stefan Hajnoczi geschrieben:
> > > > > On Thu, Feb 03, 2022 at 10:56:49AM +0000, Daniel P. Berrangé wrote:
> > > > > > On Thu, Feb 03, 2022 at 10:53:07AM +0000, Stefan Hajnoczi wrote:
> > > > > > > On Wed, Feb 02, 2022 at 06:52:34PM +0100, Nicolas Saenz Julienne 
> > > > > > > wrote:
> > > > > 1. A global default value that all new AioContext take. The QEMU main
> > > > >    loop's qemu_aio_context will use this and all IOThread AioContext
> > > > >    will use it (unless they have been overridden).
> > > > > 
> > > > >    I would define it on --machine because that's the "global" object 
> > > > > for
> > > > >    a guest, but that's not very satisfying.
> > > > 
> > > > Semantically, -machine is about the virtual hardware where as iothreads
> > > > are about the backend, so I agree it's not a good fit.
> > > > 
> > > > For the main thread, you may want to configure all the same options that
> > > > you can configure for an iothread. So to me that sounds like we would
> > > > want to allow using an iothread object for the main thread, too.
> > > > 
> > > > That would still require us to tell QEMU which iothread object should be
> > > > used for the main thread, though.
> > > 
> > > Making the main loop thread an IOThread is an interesting direction but
> > > not an easy change to make.
> > > 
> > > The main loop thread has a custom event loop that is not interchangeable
> > > with the IOThread event loop:
> > > - The main loop has a poll notifier interface for libslirp fd monitoring
> > >   integration.
> > > - The main loop is a GLib event loop but manually polls to get
> > >   nanosecond resolution timers.
> > > - The main loop has icount integration.
> > > - The main loop has the special iohandler AioContext
> > > 
> > > The IOThread event loop runs an optimized AioContext event loop instead.
> > > It falls back to regular g_main_loop_run() if there is a GSource user.
> > > 
> > > It would definitely be nice to unify the main loop with IOThread and
> > > then use --object iothread,... to configure main loop parameters.
> > > 
> > > I'm not sure if requiring that of Nicolas is fair though. The event
> > > loops in QEMU are complex and changes are likely to introduce subtle
> > > bugs or performance regressions.
> > 
> > I'm not suggesting actually running the iothread event loop instead,
> > merely using the properties of an object to configure the main thread as
> > the external user interface.
> > Whether this uses the same main loop code as today or is moved to the
> > regular iothread event loop is an implementation detail that can be
> > changed later.
> > 
> > Or we could maybe use a different object type like 'mainthread' and
> > share the properties using QOM inheritance.
> 
> That seems cleaner than trying faking an IOThread to me since I don't
> see a concrete plan to unify the two event loops.
> 
> The main loop code is in util/main-loop.c. Maybe call it --object
> main-loop? Attempting to instantiate more than one main-loop object
> should fail.

Sounds good. And if you don't create one explicitly, we'll just
internally create a default main-loop object.

Kevin

signature.asc
Description: PGP signature