[pve-devel] [PATCH-SERIES v3 qemu-server/manager/common] add and set x86-64-v2 as default model for new vms and detect best cpumodel
DERUMIER, Alexandre
alexandre.derumier at groupe-cyllene.com
Fri Jun 2 11:13:16 CEST 2023
>
> Note that migration between CPUs of different vendors is not a
> supported
> use case (it will always depend on specific models, kernel versions,
> etc.), so we can only justify not adding it to the new default model
> if
> it doesn't make life worse for everybody else.
>
> And I'd be a bit careful to jump to general conclusions just from one
> forum post.
>
> It seems like you were the one adding the flag ;)
>
>
yes, I known ^_^ (It's the default too on rhev, but they are not
supporting amd-intel migration too).
> and the LWN-archived mail linked in the commit message says
>
> > Ticket locks have an inherent problem in a virtualized case,
> > because
> > the vCPUs are scheduled rather than running concurrently (ignoring
> > gang scheduled vCPUs). This can result in catastrophic performance
> > collapses when the vCPU scheduler doesn't schedule the correct
> > "next"
> > vCPU, and ends up scheduling a vCPU which burns its entire
> > timeslice
> > spinning. (Note that this is not the same problem as lock-holder
> > preemption, which this series also addresses; that's also a
> > problem,
> > but not catastrophic).
>
> "catastrophic performance collapses" doesn't sound very promising :/
>
I have found another thread here:
https://lore.kernel.org/all/0484ea3f-4ba7-4b93-e976-098c5717166e@redhat.com/
where paolo have done benchmark with only 3% difference.
but yes, still slower anyway.
at minimum, it could be interesting to expose the flag in the gui, for
users really needed intel-amd migration.
> But if we find that
> kvm64,enforce,+kvm_pv_eoi,+kvm_pv_unhalt,+sep,+lahf_lm,+popcnt,+sse4.
> 1,+sse4.2,+ssse3
> causes issues (even if not cross-vendor live-migrating) with the
> +kvm_pv_unhalt flag, but not without, it would be a much more
> convincing
> reason against adding the flag for the new default.
>
ok ! (I will send a new patch version today)
More information about the pve-devel
mailing list