From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <f.ebner@proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id F01809D059 for <pve-devel@lists.proxmox.com>; Fri, 2 Jun 2023 13:14:10 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id D2FD828EEA for <pve-devel@lists.proxmox.com>; Fri, 2 Jun 2023 13:13:40 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for <pve-devel@lists.proxmox.com>; Fri, 2 Jun 2023 13:13:39 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 16A19483F7; Fri, 2 Jun 2023 13:13:39 +0200 (CEST) Message-ID: <e3f93fc8-653e-1886-eb48-c898c15cd6ec@proxmox.com> Date: Fri, 2 Jun 2023 13:13:38 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Content-Language: en-US To: "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>, "pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>, "aderumier@odiso.com" <aderumier@odiso.com> References: <20230522102528.186955-1-aderumier@odiso.com> <4d8191f2-4954-1e4f-a40c-51544289b2ce@proxmox.com> <036ad8c33f6af74da89eb8b9c24c1c6cda8fc938.camel@groupe-cyllene.com> <971898fbd097f9a6817a36dfedf6eae6477339bf.camel@groupe-cyllene.com> <a6758da8-c507-a909-f4fa-0dad6f7c0255@proxmox.com> <d1570c2d3bebf314851fc61bb90ee579f5945da9.camel@groupe-cyllene.com> <c034772d-9088-ac01-efc3-03249661694f@proxmox.com> <81d002bd8aeb44d29f268d44a80ec7a544914791.camel@groupe-cyllene.com> From: Fiona Ebner <f.ebner@proxmox.com> In-Reply-To: <81d002bd8aeb44d29f268d44a80ec7a544914791.camel@groupe-cyllene.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.002 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.1 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - 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 X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/> List-Post: <mailto:pve-devel@lists.proxmox.com> List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe> X-List-Received-Date: Fri, 02 Jun 2023 11:14:11 -0000 Am 02.06.23 um 11:13 schrieb DERUMIER, Alexandre: >> >> "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. So the "catastrophic performance collapses" might be a bit over the top or the situation has improved since then for non-paravirtualized locks. > at minimum, it could be interesting to expose the flag in the gui, for > users really needed intel-amd migration. > I'm not opposed to that. We could also add a short note to the docs that it might be worth a try to disable the flag if you need cross-vendor migration and the default model causes issues. IIRC, from some forum threads, other people did have success with cross-vendor migration just selecting kvm64 or Nehalem in the UI, i.e. even with the flag. Likely depends on concrete host CPU models/kernels whether it's an issue or not.