On Mon, Sep 09, 2024 at 10:25:36PM +0800, Hyman Huang wrote:
> To activate the periodic CPU throttleing feature, introduce
> the cpu-periodic-throttle.
>
> To control the frequency of throttling, introduce the
> cpu-periodic-throttle-interval.
>
> Signed-off-by: Hyman Huang <yong.huang@smartx.com>
Considering that I would still suggest postcopy over auto-converge, IMO we
We are considering the hybrid of precopy and postcopy in fact, and i
entirely agree with what you are saying: postcopy migration is an alternative
solution to deal with migrations that refuse to converge, or take too long
to converge. But enabling this feature may not be easy in production since the
recovery requires upper apps to interface, the hugepages and spdk/dpdk
scenarios also need to be considered and re-test.
Considering auto-converge is the main policy in the industry, the optimization
may still make sense. We would like to try to optimize the auto-converge in huge
VM case and, IMHO, it doesn't conflict with postcopy.
should be cautious on adding more QMP interfaces on top of auto-converge,
because that means more maintenance burden everywhere.. and it's against
our goal to provide, hopefully, one solution for the long term for
convergence issues.
Postcopy has a major issue with VFIO, but auto converge isn't anything
better from that regard.. as we can't yet throttle a device so far anyway.
Throttling of DMA probably means DMA faults, then postcopy might be doable
too. Meanwhile we're looking at working out 1G postcopy at some point.
So I wonder whether we can make any further optmization for auto-converge
(if we still really want that..) to be at least transparent, so that they
Thanks for the advice and of course yes.
So, at first, We'll try to avoid adding the new periodic throttle parameter
and make it be transparent ?
get auto enabled on new machine types. If we really want some knobs to
control, we can still expose via -global migration.x-* parameters, but then
they'll be all debug tunables only, perhaps that can at least reduce
burdens to QMP maintainers and Libvirt side.
Thanks,
--
Peter Xu