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 018081FF13C for ; Thu, 19 Mar 2026 11:06:48 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id CFF0A18F87; Thu, 19 Mar 2026 11:07:02 +0100 (CET) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 19 Mar 2026 11:06:29 +0100 Message-Id: Subject: Re: [RFC PATCH-SERIES many 00/36] dynamic scheduler + load rebalancer From: "Dominik Rusovac" To: "Daniel Kral" , "Thomas Lamprecht" , X-Mailer: aerc 0.20.0 References: <20260217141437.584852-1-d.kral@proxmox.com> <3fcd4459-e5ff-48ca-8b70-53411a666247@proxmox.com> In-Reply-To: X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1773914747115 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.360 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: EUUR2PGNP2NR4VY5HNVJLGSKW66QUILH X-Message-ID-Hash: EUUR2PGNP2NR4VY5HNVJLGSKW66QUILH X-MailFrom: d.rusovac@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: On Thu Mar 19, 2026 at 10:12 AM CET, Daniel Kral wrote: [snip]=20 >> Also, load() gives CPU and memory equal weight, but PveTopsisAlternative >> gives memory 5-10x more weight than CPU. >> So the brute-force and TOPSIS paths use different ideas of "balance", TOPSIS and brute-force are different approaches, one difference being that, in contrast to brute-force, "imbalance", respectively, its dual notion, "balance", does not directly play a role in TOPSIS.=20 While brute-force is a quite blunt approach, simply comparing how potential migrations affect the imbalance value, the optimization performed by TOPSIS is more fine-grained, aiming at minimizing designated weighted criteria, which may affect the imbalance value in a positive way, even though the imbalance value of an alternative is not a criterion that directly affects how TOPSIS makes decisions.=20 This is not to say that "imbalance" cannot play a role in the TOPSIS approach. We may very well add a designated "imbalance" criterion that aligns with the "imbalance" notion brute-force is based on. Long story short, ATM IMO, brute-force and TOPSIS are incomparable in that regard. >> either fix that or document why it's fine. > > Yes, I'll consider allowing at least a weighted load, which essentially > is the same. Though the TOPSIS method doesn't really have the notion of > an imbalance, but optimizes for low peaks and ~RMS values of the stats. > I'll check this once more. CC @Dominik if you have more insight here as > you took a good look at how TOPSIS behaves in specific scenarios. > Should we not opt for adding the notion of imbalance used by brute-force as a designated criterion to TOPSIS, allowing a weigthed load seems a like good compromise to me. However, while this would allow for configuring how either stat affects the imbalance value, IMO, brute-force and TOPSIS would remain somewhat incomparable with regards to "imbalance". [snip]