On Thu, Jun 02, 2022 at 09:18:04 +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.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
docs/formatdomain.rst | 5 ++
src/conf/domain_conf.c | 57 +++++++++++++++++++
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, 88 insertions(+)
diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
index de085f616a..5e0019c574 100644
--- a/docs/formatdomain.rst
+++ b/docs/formatdomain.rst
[...]
@@ -699,6 +700,10 @@ host/guest with many LUNs. :since:`Since 1.2.8
(QEMU only)`
The element has two optional attributes ``pool_min`` and ``pool_max`` which
allow setting lower and upper boundary for number of worker threads for
given IOThread. :since:`Since 8.4.0`
+``mainloop``
+ The optional ``mainloop`` element contains two optional attributes
+ ``pool_min`` and ``pool_max`` which allow setting lower and upper boundary
+ for number of worker threads for the main event loop. :since:`Since 8.4.0`
I don't think we should use the qemu term "main loop" here. In general
we refer to the qemu process as emulator, including stuff like
emulatorpin and similar.
Now the slight drawback from using 'emulator' is that we already have
'emulator' as part of <devices> so adding another one here is not a good
idea.
Having 'tread_pool_max'/min attribute on the emulator tag is a bit ugly
but feasible and would bring it to be a bit more relevant.
Also the documentation paragraph does a really bad job at explaining how
to use these knobs and what they control so please update it a bit.
Also note the other things outlined in previous replies namely:
- version being 8.5.0
- 'long long' being too much and too complicated
- using the 'tread_' prefix for the fields