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 DDD9C1FF179 for ; Wed, 12 Nov 2025 11:48:38 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 2EF731EEC3; Wed, 12 Nov 2025 11:49:24 +0100 (CET) Message-ID: <9b51dec9-a6e3-429f-8f5f-4138f658c381@proxmox.com> Date: Wed, 12 Nov 2025 11:49:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta To: Proxmox VE development discussion , Daniel Kral References: <20251027164513.542678-1-d.kral@proxmox.com> <20251027164513.542678-3-d.kral@proxmox.com> Content-Language: en-US From: Thomas Lamprecht In-Reply-To: <20251027164513.542678-3-d.kral@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1762944535969 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.024 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 perl-rs v3 1/2] pve-rs: resource_scheduling: allow granular usage changes 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" nicer commit subject would be: pve resource scheduling: allow granular usage changes Am 27.10.25 um 17:46 schrieb Daniel Kral: > Implements a simple bidirectional map to track which service usages have > been added to nodes, so that these can be removed later individually. > > The `StaticNodeUsage` is newly initialized on every invocation of > score_nodes_to_start_service(...) instead of updating the values on > every call of `add_service_usage_to_node(...)` to reduce the likelihood > of introducing numerical instability caused by floating-point operations > done on the `cpu` field. > > The StaticServiceUsage is added to the HashMap<> in StaticNodeInfo to > reduce unnecessary indirection when summing these values in > score_nodes_to_start_service(...). > > Signed-off-by: Daniel Kral > Reviewed-by: Fiona Ebner > --- > Needs a build dependency bump for > librust-proxmox-resource-scheduling-dev and a versioned breaks for > pve-ha-manager. The latter only due to the (signature) change to add_service_usage_to_node, or? While versioned breaks can be done, if it's somewhat easy to avoid them it's always better to do so, especially as it makes downgrades much easier Can we keep backward compat without having to bend to much backwards? E.g. adding a new method for the new more granular way while keeping add_service_usage_to_node as is, like "record_service_usage_for_node" (or just slap a 2 at the end of the method name is also a simple trick that, while not beautiful, works and avoids bikeshedding). _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel