Nicolas Saenz Julienne <nsaen...@redhat.com> writes: > The thread pool regulates itself: when idle, it kills threads until > empty, when in demand, it creates new threads until full. This behaviour > doesn't play well with latency sensitive workloads where the price of > creating a new thread is too high. For example, when paired with qemu's > '-mlock', or using safety features like SafeStack, creating a new thread > has been measured take multiple milliseconds. > > In order to mitigate this let's introduce a new 'EventLoopBase' > property to set the thread pool size. The threads will be created during > the pool's initialization or upon updating the property's value, remain > available during its lifetime regardless of demand, and destroyed upon > freeing it. A properly characterized workload will then be able to > configure the pool to avoid any latency spikes. > > Signed-off-by: Nicolas Saenz Julienne <nsaen...@redhat.com> > Reviewed-by: Stefan Hajnoczi <stefa...@redhat.com>
[...] > diff --git a/qapi/qom.json b/qapi/qom.json > index e5f31c4469..06b8c3d10b 100644 > --- a/qapi/qom.json > +++ b/qapi/qom.json > @@ -506,9 +506,17 @@ > # > # @aio-max-batch: maximum number of requests in a batch for the AIO engine, > # 0 means that the engine will use its default. > +# > +# @thread-pool-min: minimum number of threads readily available in the thread > +# pool (default:0, since 7.1) What do you mean by "readily available in the thread pool"? > +# > +# @thread-pool-max: maximum number of threads the thread pool can contain > +# (default:64, since 7.1) > ## If you add "Since: 7.1" in the previous patch, then the "since 7.1" here need to go. > { 'struct': 'EventLoopBaseProperties', > - 'data': { '*aio-max-batch': 'int' } } > + 'data': { '*aio-max-batch': 'int', > + '*thread-pool-min': 'int', > + '*thread-pool-max': 'int' } } > > ## > # @IothreadProperties: [...]