On Tue, Jun 07, 2022 at 14:52:57 +0200, Michal Privoznik wrote:
As of v7.0.0-877-g70ac26b9e5 QEMU exposes its main event loop as
an QMP object. In the very next commit (v7.0.0-878-g71ad4713cc)
it was extended for thread-pool-min and thread-pool-max
attributes. Expose them under new <mainloop/> element.
Please fix the summary and commit message. Make sure to mention the name
of the element.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
docs/formatdomain.rst | 9 +++
src/conf/domain_conf.c | 63 +++++++++++++++++++
src/conf/domain_conf.h | 8 +++
src/conf/schemas/domaincommon.rng | 15 +++++
src/conf/virconftypes.h | 2 +
.../iothreads-ids-pool-sizes.xml | 1 +
6 files changed, 98 insertions(+)
diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
index 2aa39b2f63..22eb540ba3 100644
--- a/docs/formatdomain.rst
+++ b/docs/formatdomain.rst
@@ -677,6 +677,7 @@ host/guest with many LUNs. :since:`Since 1.2.8 (QEMU only)`
<iothread id="6"/>
<iothread id="8" thread_pool_min="2"
thread_pool_max="32"/>
</iothreadids>
+ <defaultiothread thread_pool_min="8"
thread_pool_max="16">
...
</domain>
@@ -699,6 +700,14 @@ host/guest with many LUNs. :since:`Since 1.2.8 (QEMU only)`
The element has two optional attributes ``thread_pool_min`` and
``hread_pool_max`` which allow setting lower and upper boundary for number
of worker threads for given IOThread. :since:`Since 8.5.0`
+``defaultiothread``
+ The element then can have ``thread_pool_min`` and/or ``thread_pool_max``
+ attributes, which control the lower and upper boundary for number of worker
+ threads for the emulator. Emulator might be multithreaded and spawn so
+ called worker threads on demand. In general neither of these attributes
+ should be set (leaving the emulator use its own default values), unless the
+ emulator runs in a real time workload and thus can't afford unpredictability
+ of time it takes to spawn new worker threads. :since:`Since 8.5.0`
This description doesn't seem to capture what actually the
'defaultiothread' element represents. It starts right away by describing
it's arguments. Users might be confused.
I don't have a specific suggestion though.
The code looks good:
Reviewed-by: Peter Krempa <pkrempa(a)redhat.com>