Nicolas Saenz Julienne <nsaen...@redhat.com> writes: > 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"?
Works for me, thanks! >> > +# >> > +# @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.
