From: "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>
To: "pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>,
"aderumier@odiso.com" <aderumier@odiso.com>,
"f.ebner@proxmox.com" <f.ebner@proxmox.com>
Subject: Re: [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
Date: Fri, 2 Jun 2023 09:13:16 +0000 [thread overview]
Message-ID: <81d002bd8aeb44d29f268d44a80ec7a544914791.camel@groupe-cyllene.com> (raw)
In-Reply-To: <c034772d-9088-ac01-efc3-03249661694f@proxmox.com>
>
> 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)
next prev parent reply other threads:[~2023-06-02 9:13 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-22 10:25 Alexandre Derumier
2023-05-22 10:25 ` [pve-devel] [PATCH v3 qemu-server 1/7] cpuconfig: add new x86-64-vX models Alexandre Derumier
2023-05-31 11:08 ` Fiona Ebner
2023-05-31 15:08 ` DERUMIER, Alexandre
2023-06-01 9:17 ` Fiona Ebner
2023-06-01 11:27 ` DERUMIER, Alexandre
2023-05-22 10:25 ` [pve-devel] [PATCH v2 pve-manager 1/1] qemu: processor : set x86-64-v2 as default cputype for create wizard Alexandre Derumier
2023-05-22 10:25 ` [pve-devel] [PATCH pve-common 1/1] read_cpuinfo: add msr support Alexandre Derumier
2023-05-22 10:25 ` [pve-devel] [PATCH v3 qemu-server 2/7] cpumodel: add cpu models with flags Alexandre Derumier
2023-05-22 10:25 ` [pve-devel] [PATCH v3 qemu-server 3/7] cpumodel: compute qemu supported flags Alexandre Derumier
2023-05-22 10:25 ` [pve-devel] [PATCH v3 qemu-server 4/7] cpuconfig: add get_host_cpu_flags Alexandre Derumier
2023-05-22 10:25 ` [pve-devel] [PATCH v3 qemu-server 5/7] cpuconfig: add find_best_cpumodel Alexandre Derumier
2023-05-22 10:25 ` [pve-devel] [PATCH v3 qemu-server 6/7] cpuconfig: add find_hosts_common_flags Alexandre Derumier
2023-05-22 10:25 ` [pve-devel] [PATCH v3 qemu-server 7/7] add best cpu model detection tests Alexandre Derumier
2023-05-31 11:36 ` [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 Fiona Ebner
2023-05-31 14:34 ` DERUMIER, Alexandre
2023-06-01 8:34 ` Fiona Ebner
2023-06-01 9:06 ` DERUMIER, Alexandre
2023-06-03 14:14 ` Thomas Lamprecht
2023-06-04 6:29 ` DERUMIER, Alexandre
2023-06-03 14:05 ` Thomas Lamprecht
2023-06-01 9:34 ` Fiona Ebner
2023-06-01 11:37 ` DERUMIER, Alexandre
2023-06-01 13:53 ` DERUMIER, Alexandre
2023-06-01 15:56 ` Fiona Ebner
2023-06-01 21:15 ` DERUMIER, Alexandre
2023-06-02 7:28 ` Fiona Ebner
2023-06-02 9:13 ` DERUMIER, Alexandre [this message]
2023-06-02 11:13 ` Fiona Ebner
2023-06-02 11:44 ` DERUMIER, Alexandre
2023-06-03 14:21 ` Thomas Lamprecht
[not found] ` <8277a27b-a70f-b731-69f7-fc9ae69b2da2@binovo.es>
2023-06-01 16:00 ` Fiona Ebner
2023-06-02 12:41 ` Aaron Lauterer
2023-06-02 14:15 ` DERUMIER, Alexandre
2023-06-02 16:09 ` Aaron Lauterer
2023-06-02 16:27 ` DERUMIER, Alexandre
[not found] ` <fa3565e5-3a9c-9348-f291-554a0e0d6628@binovo.es>
2023-06-06 9:15 ` Fiona Ebner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=81d002bd8aeb44d29f268d44a80ec7a544914791.camel@groupe-cyllene.com \
--to=alexandre.derumier@groupe-cyllene.com \
--cc=aderumier@odiso.com \
--cc=f.ebner@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal