From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id C97BF1FF15C for ; Fri, 17 Oct 2025 17:58:45 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 6B6C27879; Fri, 17 Oct 2025 17:59:05 +0200 (CEST) Mime-Version: 1.0 Date: Fri, 17 Oct 2025 17:59:01 +0200 Message-Id: From: "Daniel Kral" To: "Fiona Ebner" , "Proxmox VE development discussion" X-Mailer: aerc 0.20.0 References: <20250930142021.366529-1-d.kral@proxmox.com> <20250930142021.366529-13-d.kral@proxmox.com> In-Reply-To: X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1760716737717 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.015 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 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. 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 ha-manager 9/9] manager: make service node usage computation more granular 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: , Reply-To: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" On Fri Oct 17, 2025 at 2:42 PM CEST, Fiona Ebner wrote: > Am 30.09.25 um 4:21 PM schrieb Daniel Kral: >> The $online_node_usage is built on every call to manage(...) now, but >> can be reduced to only be built on any scheduler mode change (including >> initialization or error path to be complete). >> >> This allows recompute_online_node_usage(...) to be reduced to >> adding/removing nodes whenever these become online or are not online >> anymore and handle the service usage updates whenever these change. >> Therefore, recompute_online_node_usage(...) must only be called once in >> manage(...) after $ns was properly updated. >> >> Note that this makes the ha-manager not acknowledge any hotplug changes >> to the guest configs anymore as long as the HA resource state doesn't >> change. > > I'm not comfortable with that to be honest, because it would not just be > a very badly timed large change that can lead to unexpected decisions, > but an accumulation of smaller changes without any bad timing. > >> >> Signed-off-by: Daniel Kral >> --- >> If we go for this patch, then we would need some mechanism to update the >> static usage for a single or all HA resources registered in >> $online_node_usage at once (or just rebuilt $online_node_usage at that >> point..). > > You mean triggered from qemu-server/pve-container upon update? In > combination with that it would be acceptable I think. Question is, do we > want to spend even more time optimizing the static scheduler, or just > apply a v2 without patch 9/9 and rather focus on getting a PSI-based > scheduler going? Right, the patch was also more of a leftover from an initial approach but wanted to still get feedback if there's any benefit to do it that way, but in hindsight it probably only adds unnecessary complexity and might even be an overhead at long last which could introduce weird bugs. Especially since the performance now is very acceptable, I don't see a reason to optimize here further until we find a better reason for that. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel