
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@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@redhat.com>