On 6/6/22 13:40, Daniel P. Berrangé wrote:
On Thu, Jun 02, 2022 at 01:54:39PM +0200, Peter Krempa wrote:
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@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.
It isn't even especially part of the QEMU main loop IIUC.
Rather it is setting up a pool of threads that are used for serving I/O, when no specific I/O thread is configurd for the guest.
Perhaps it can be '<defaultiothread/>' or something along those lines, to make it clear it is an I/O related tunable.
Right, I'd rather avoid putting it as an attribute to <emulator/> since we have a whole section dedicated to performance tuning. Not to mention <emulator/> lives under <devices/> and I don't think we put performance related knobs there. I didn't object to Peter's suggestion because I don't have better idea. So are you suggesting that <defaultiothread/> would be at the same level as <iothreads/> and <iothreadids/> or it would be nested somewhere? <domain> <name/> <iothreads>4</iothreads> <iothreadids> <iothread id="1" thread_pool_min="2" thread_pool_max="8"/> <iothread id="2"/> <iothreadids> <defaultiothread thread_pool_min="8" thread_pool_max="8"/> <devices/> </domain> This looks relatively nice. Michal