From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 1E7D09674F for ; Wed, 25 Jan 2023 11:52:42 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id E2B82D809 for ; Wed, 25 Jan 2023 11:52:11 +0100 (CET) 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)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Wed, 25 Jan 2023 11:52:11 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id E1BF946112; Wed, 25 Jan 2023 11:52:10 +0100 (CET) Message-ID: Date: Wed, 25 Jan 2023 11:52:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Content-Language: en-US To: "DERUMIER, Alexandre" , "pve-devel@lists.proxmox.com" , "aderumier@odiso.com" References: <20230104064303.2898194-1-aderumier@odiso.com> <20230104064303.2898194-9-aderumier@odiso.com> <3a360312-42c0-6e97-c0e3-6cc70285f3eb@proxmox.com> <5c097397-3777-66a9-579c-b7d99941c399@proxmox.com> From: Fiona Ebner In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 3.084 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -1.148 Looks like a legit reply (A) RCVD_IN_DNSWL_HI -5 Sender listed at https://www.dnswl.org/, high trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [PATCH v2 qemu-server 8/9] memory: add virtio-mem support X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2023 10:52:42 -0000 Am 25.01.23 um 11:28 schrieb DERUMIER, Alexandre: >> Sure, doing it in parallel is perfectly fine. I'm just thinking that >> switching gears (too early) and redirecting the request might not be >> ideal. You also issue an additional qom-set to go back to >> $virtiomem->{current} * 1024 *1024 if a request didn't make progress >> in >> time. But to be sure that request worked, we'd also need to monitor >> it >> ;) I think issuing that request is fine as-is, but if there is a >> "hanging" device, we really can't do much. And I do think the user >> should be informed via an appropriate error if there is a problematic >> device. >> >> Maybe we can use 10 seconds instead of 5 (2-3 seconds already sounds >> too >> close to 5 IMHO), so that we have a good margin, and just die instead >> of >> trying to redirect the request to another device. After issuing the >> reset request and writing our best guess of what the memory is to the >> config of course. >> > I forgot to say, than it don't timeout 5s after the qom-set, > but timeout after 5s if no memory change is detected by qom-get. > I'm reseting the retry counter if a change is detected. > (so 5s is really big, in real, when it's blocking for 1s, it's really > blocking) I saw that and thought the "It can take 2-3second on unplug on bigger setup" means that it can take this long for a change to happen. Since that's not the case, 5 seconds can be fine of course :) >> If it really is an issue in practice that certain devices often take >> too >> long for whatever reason, we can still add the redirect logic. But >> starting out, I feel like it's not worth the additional complexity. >> > The real only reason will be on unplug, if memory block are unmovable > (kernel reserved) or with big fragmentation, no available block.(with > 4MB granurality it's difficult to reach, but with bigger maxmem and > bigger block, we have more chance to trigger it. (with 1GB > hugepage,it's more easy to trigger it too I think) > > But if you want something more simple, > > I can something like before, split memory by number of sockets, > and if we have an error on 1 socket, don't try to redispatch again > remaining block of this socket on other nodes. Hope it's not too much work. I do think we should wait for some user demand before adding the redispatch feature (and having it as a separate patch helps to review and for git history). But feel free to include it if you already experienced the above-mentioned issue a few times ;)