On 1/11/23 11:09, Thomas Huth wrote:
On 05/01/2023 15.53, Pierre Morel wrote:
The modification of the CPU attributes are done through a monitor
commands.
s/commands/command/
thx
It allows to move the core inside the topology tree to optimise
the cache usage in the case the host's hypervizor previously
s/hypervizor/hypervisor/
yes, thx
moved the CPU.
The same command allows to modifiy the CPU attributes modifiers
s/modifiy/modify/
thx
like polarization entitlement and the dedicated attribute to notify
the guest if the host admin modified scheduling or dedication of a vCPU.
With this knowledge the guest has the possibility to optimize the
usage of the vCPUs.
Hmm, who is supposed to call this QMP command in the future? Will there
be a new daemon monitoring the CPU changes in the host? Or will there be
a libvirt addition for this? ... Seems like I still miss the big picture
here...
Thomas
The first idea is to provide a daemon that could get the information on
real CPU from the host sysfs and to specify the vCPU topology according
to the real CPU.
There could be a libvirt command for this too.
The big picture is to provide the guest OS with the real topology so
that the guest OS can make decisions on the scheduling.
I think that a daemon is perfect I can not imagine anything else than
the alternative:
1) Do not specify anything and let things go more or less random as
today by setting the cores in socket,book,drawer in an incremental way.
2) specifying the exact topology
So I do not see the point to let the user or even libvirt specify a
random topology if it is specified it must be exact.
Regards,
Pierre
--
Pierre Morel
IBM Lab Boeblingen
