[PATCH 14/16] conf: Expose QEMU's main loop object

Michal Prívozník mprivozn at redhat.com
Tue Jun 7 08:06:16 UTC 2022


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 at 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



More information about the libvir-list mailing list