From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 4FAEE1FF13C for ; Thu, 19 Mar 2026 12:34:52 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id B3A041C171; Thu, 19 Mar 2026 12:35:05 +0100 (CET) Message-ID: Date: Thu, 19 Mar 2026 12:35:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [RFC PATCH-SERIES many 00/36] dynamic scheduler + load rebalancer To: Daniel Kral , pve-devel@lists.proxmox.com References: <20260217141437.584852-1-d.kral@proxmox.com> <3fcd4459-e5ff-48ca-8b70-53411a666247@proxmox.com> Content-Language: en-US From: Thomas Lamprecht In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1773920058397 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.010 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 SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: W7DFQ5BYIZWG7K4PMBVVQHP3H665C3MU X-Message-ID-Hash: W7DFQ5BYIZWG7K4PMBVVQHP3H665C3MU X-MailFrom: t.lamprecht@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Am 19.03.26 um 10:12 schrieb Daniel Kral: > Right, the visibility change doesn't make a lot of sense. > > I'll go for copying the logic in scheduler.rs, which will then turn into > add_started_service() in the next patch. add_cpu_usage() is still used > by StaticNodeUsage::add_service_usage(), which is needed to be able to > build older pve-rs with the newer crate. > > In general, should I add a #[deprecated] notice or just a comment for > these things? In that case a [deprecated] marker would be indeed fine to do, it's only temporarily to allow rolling out this while not break builds. (i.e., not something that's going to "annoy us with no remedy" for a while).