On Fri, 2022-04-22 at 13:15 +0200, Markus Armbruster wrote: > 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"?
How about "minimum number of threads reserved 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. Noted. -- Nicolás Sáenz
