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

[Stefan Hajnoczi]

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.

Stefan

signature.asc
Description: PGP signature