Re: [RFC PATCH-SERIES many 00/36] dynamic scheduler + load rebalancer

["Dominik Rusovac" <d.rusovac@proxmox.com>]

On Thu Mar 19, 2026 at 10:12 AM CET, Daniel Kral wrote:

[snip] 

>> 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. 

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. 

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]