Re: [PATCH proxmox 03/15] fix #7993: resource-scheduling: lift to weighted load balancing

["Daniel Kral" <d.kral@proxmox.com>]

Thanks a lot for working on this, nice work! Especially the cover letter
is a very interesting analysis and read!

Looks generally sound, though there are some comments inline on having
backwards and forwards compatibility and some patch cleanup.

On Wed Oct 21, 2026 at 10:59 AM CEST, Dominik Rusovac wrote:
> Blend weights into node load computation, effectively replacing
> arithmetic mean [0] of the node's CPU load and memory usage with
> weighted arithmetic mean [1] thereof.
>
> Expose customizable weights for bruteforce method. For TOPSIS method
> expose customizable weights for average cpu and average memory only. The
> weights of highest cpu and highest memory are not independently
> configurable; each is derived as twice as much as its average
> counterpart, that is, the weight of highest cpu/memory is twice as much
> as the weight of average cpu/memory. This makes it possible to
> prioritize balancing a specific computational resource while also
> preserving the ratio between a resource's two criteria, as introduced in
> [2].
>
> Apart from the achieved imbalance, expose the score of a scored
> migration. Moreover, primarily order scored migrations by their score
> (lower is better), falling back to imbalance when scores tie, and
> finally to the migration itself if both tie -- ensuring a total,
> deterministic order even when several candidates achieve the exact same
> score. Add basic unit test for this.
>
> Refactor existing tests.
>
> [0] https://en.wikipedia.org/wiki/Arithmetic_mean
> [1] https://en.wikipedia.org/wiki/Weighted_arithmetic_mean
> [2] https://lore.proxmox.com/all/20221110143800.98047-3-f.ebner@proxmox.com/

Changes which were applied should be referenced as commit refs rather
than the patch on the mailing list, i.e. here

    commit 2b325aa5 ("add pve_static module")

>
> Signed-off-by: Dominik Rusovac <d.rusovac@proxmox.com>
> ---
>  proxmox-resource-scheduling/src/node.rs       |  27 +-
>  proxmox-resource-scheduling/src/pve_static.rs |   3 +-
>  proxmox-resource-scheduling/src/scheduler.rs  | 248 +++++++++++++-----
>  .../tests/scheduler.rs                        | 136 ++++++++--
>  4 files changed, 327 insertions(+), 87 deletions(-)
>
> diff --git a/proxmox-resource-scheduling/src/node.rs b/proxmox-resource-scheduling/src/node.rs
> index 3c7ed393..f9dc5b16 100644
> --- a/proxmox-resource-scheduling/src/node.rs
> +++ b/proxmox-resource-scheduling/src/node.rs
> @@ -51,9 +51,30 @@ impl NodeStats {
>          self.mem as f64 / self.maxmem as f64
>      }
>  
> -    /// Returns a combined node usage as a percentage.
> -    pub fn load(&self) -> f64 {
> -        (self.cpu_load() + self.mem_load()) / 2.0
> +    /// Returns the node load as the [weighted arithmetic mean] of [`Self::cpu_load`] and
> +    /// [`Self::mem_load`].
> +    ///
> +    /// `cpu_weight` controls how much [`Self::cpu_load`] contributes to the load, analogously,
> +    /// `mem_weight` controls how much [`Self::mem_load`] contributes to the load; the higher the
> +    /// weight, the more that resource dominates the result.

nit: can be documented in struct NodeStatsWeights, see below for more

> +    ///
> +    /// NOTE:
> +    /// - the weights have to be positive
> +    /// - only the weights' ratio matters, not their absolute magnitude
> +    /// - a weight of 0.0 means no contribution to the load
> +    /// - [weighted arithmetic mean] is the same as [arithmetic mean] if the weights are equal
> +    ///
> +    /// [weighted arithmetic mean]: https://en.wikipedia.org/wiki/Weighted_arithmetic_mean
> +    /// [arithmetic mean]: https://en.wikipedia.org/wiki/Arithmetic_mean
> +    pub fn load(&self, cpu_weight: f64, mem_weight: f64) -> f64 {
> +        let weights_sum = cpu_weight + mem_weight;
> +
> +        if weights_sum == 0.0 {
> +            // both, cpu and mem, should not contribute to the load, so there is no load
> +            return 0.0;
> +        }
> +
> +        (self.cpu_load() * cpu_weight + self.mem_load() * mem_weight) / weights_sum
>      }

Would be nice to have a separate weighted_load() next to the existing
load() for backwards compatibility.

And for some type of forwards compatibility, maybe something like

#[derive(Copy, Clone, Debug)]
pub struct NodeStatsWeights {
    pub cpu_weight: f64,
    pub mem_weight: f64,
}

impl Default for NodeStatsWeights {
    fn default() -> Self {
        Self {
            cpu_weight: 1,
            mem_weight: 1,
        }
    }
}

pub fn weighted_load(&self, weights: &NodeStatsWeights) -> f64 {}

?

The NodeStatsWeights struct can then be used in all callers of
weighted_load() and therefore the members and their documentation do not
need to be repeated there.

Though we'd probably need a default for TOPSIS as well, because there it
should be 1 : 5 with cpu : mem for backwards compatibility...


On another note, adding a new field to NodeStatsWeights then would
unfortunately break external callers, except if every external caller
allocates it with:

let weights = NodeStatsWeights {
    cpu_weight: 2,
    mem_weight: 3,
    ..Default::default()
}

#[non_exhaustive] would be nice here, but unfortunately that prevents
external callers to use the literal struct syntax with functional update
syntax as above [0] and we would need to build a proper interface to set
the weights with methods... We can also do that, but adds some code just
for that.

[0] https://doc.rust-lang.org/reference/attributes/type_system.html#r-attributes.type-system.non_exhaustive.construction

>  }
>  
> diff --git a/proxmox-resource-scheduling/src/pve_static.rs b/proxmox-resource-scheduling/src/pve_static.rs
> index 40b76cbc..98d64907 100644
> --- a/proxmox-resource-scheduling/src/pve_static.rs
> +++ b/proxmox-resource-scheduling/src/pve_static.rs
> @@ -96,5 +96,6 @@ pub fn score_nodes_to_start_service<T: AsRef<StaticNodeUsage>>(
>  
>      let scheduler = Scheduler::from_nodes(nodes);
>  
> -    scheduler.score_nodes_to_start_resource(*service)
> +    // uses original empirically determined TOPSIS weights
> +    scheduler.score_nodes_to_start_resource(*service, 1, 5)
>  }
> diff --git a/proxmox-resource-scheduling/src/scheduler.rs b/proxmox-resource-scheduling/src/scheduler.rs
> index a12cd519..0690385d 100644
> --- a/proxmox-resource-scheduling/src/scheduler.rs
> +++ b/proxmox-resource-scheduling/src/scheduler.rs
> @@ -8,6 +8,9 @@ use std::{
>      collections::BinaryHeap,
>  };
>  
> +/// Constant to control the ratio of the weights of a resource's average and highest criteria.
> +pub const TOPSIS_AVERAGE_VS_HIGHEST_FACTOR: f64 = 2.0;
> +
>  /// The scheduler view of a node.
>  #[derive(Clone, Debug)]
>  pub struct NodeUsage {
> @@ -69,23 +72,6 @@ fn node_stats_after_migration(candidate: &MigrationCandidate, node: &NodeUsage)
>      new_stats
>  }
>  
> -criteria_struct! {
> -    /// A given alternative.
> -    struct PveTopsisAlternative {
> -        #[criterion("average CPU", -1.0)]
> -        average_cpu: f64,
> -        #[criterion("highest CPU", -2.0)]
> -        highest_cpu: f64,
> -        #[criterion("average memory", -5.0)]
> -        average_memory: f64,
> -        #[criterion("highest memory", -10.0)]
> -        highest_memory: f64,
> -    }
> -
> -    const N_CRITERIA;
> -    static PVE_HA_TOPSIS_CRITERIA;
> -}
> -

would prefer keeping the struct, so there's still a type giving the
numbers some name.

struct PveTopsisAlternative {
    average_cpu: f64,
    highest_cpu: f64,
    average_memory: f64,
    highest_memory: f64,
}

const N_CRITERIA = 4;

impl From<PveTopsisAlternative> for [f64; N_CRITERIA] {
    fn from(alternative: PveTopsisAlternative) -> Self {
        [
            alternative.average_cpu,
            alternative.highest_cpu,
            alternative.average_memory,
            alternative.highest_memory,
        ]
    }
}

>  #[derive(Clone, Debug)]
>  pub struct Scheduler {
>      nodes: Vec<NodeUsage>,
> @@ -111,12 +97,20 @@ pub struct ScoredMigration {
>      pub migration: Migration,
>      /// The expected node imbalance after the migration.
>      pub imbalance: f64,
> +    /// The score.
> +    ///
> +    /// - corresponds to imbalance of weighted loads for
> +    ///   [`Scheduler::score_best_balancing_migration_candidates`]
> +    /// - corresponds to distance to ideal best alternatives for
> +    ///   [`Scheduler::score_best_balancing_migration_candidates_topsis`]
> +    pub score: f64,

As discussed off-list, I'm not sure whether we should expose the 'score'
as it isn't relevant to the feedback loop now.

>  }
>  
>  impl Ord for ScoredMigration {
>      fn cmp(&self, other: &Self) -> Ordering {
> -        self.imbalance
> -            .total_cmp(&other.imbalance)
> +        self.score
> +            .total_cmp(&other.score)
> +            .then(self.imbalance.total_cmp(&other.imbalance))
>              .then(self.migration.cmp(&other.migration))

AFAICT this could lead to unwanted load balancing decisions at least for
the brute force case:

If a user configures cpu_weight = 0, mem_weight = 1, i.e., do not
include CPU usage in load balancing decisions, then if two migration
candidates would have the equal change in memory distribution but
different ones in CPU (i.e. equal imbalance values), it would then still
include CPU usage in the load balancing decision with the unweighted
'imbalance' value.

Of course, this wouldn't even be really noticable, so might not be an
issue.

Though I wonder whether calculating both the unweighted and weighted
node imbalance values for all migration candidates at least in the
bruteforce case does increase the computational load for a relatively
small special case (i.e. equal weighted imbalance values).

>      }
>  }
> @@ -136,19 +130,21 @@ impl PartialEq for ScoredMigration {
>  impl Eq for ScoredMigration {}
>  
>  impl ScoredMigration {
> -    pub fn new<T: Into<Migration>>(migration: T, imbalance: f64) -> Self {
> -        // Depending on how the imbalance is calculated, it can contain minor approximation errors.
> -        // As this struct implements the Ord trait, users of the struct's cmp() can run into cases,
> -        // where the imbalance is the same up to the significant digits in base 10, but treated as
> -        // different values.
> +    pub fn new<T: Into<Migration>>(migration: T, imbalance: f64, score: f64) -> Self {
> +        // Depending on how the imbalance or score is calculated, it can contain minor approximation
> +        // errors. As this struct implements the Ord trait, users of the struct's cmp() can run into
> +        // cases, where the imbalance or score is the same up to the significant digits in base 10,
> +        // but treated as different values.
>          //
>          // Therefore, truncate any non-significant digits to prevent these cases.
>          let factor = 10_f64.powi(f64::DIGITS as i32);
>          let truncated_imbalance = f64::trunc(factor * imbalance) / factor;
> +        let truncated_score = f64::trunc(factor * score) / factor;
>  
>          Self {
>              migration: migration.into(),
>              imbalance: truncated_imbalance,
> +            score: truncated_score,
>          }
>      }
>  }
> @@ -179,15 +175,15 @@ impl Scheduler {
>          }
>      }
>  
> -    /// Maps the current node usages to a [`PveTopsisAlternative`].
> +    /// Maps the current node usages to a TOPSIS alternative.
>      ///
> -    /// The [`PveTopsisAlternative`] is derived by calculating a modified version of the root mean
> -    /// square (RMS) and maximum value of each stat in the node usages.
> +    /// The alternative is derived by calculating a modified version of the root mean square (RMS)
> +    /// and maximum value of each stat in the node usages.
>      fn topsis_alternative_with(
>          &self,
>          map_node_stats: impl Fn(&NodeUsage) -> NodeStats,
> -    ) -> PveTopsisAlternative {
> -        let len = self.nodes.len();
> +    ) -> [f64; 4] {
> +        let len = self.nodes.len() as f64;
>  
>          // Base values on percentages to allow comparing nodes with different stats.
>          let mut highest_cpu = 0.0;
> @@ -209,55 +205,79 @@ impl Scheduler {
>  
>          // Add 1.0 to avoid boosting tiny differences: e.g. 0.004 is twice as much as 0.002, but
>          // 1.004 is only slightly more than 1.002.
> -        PveTopsisAlternative {
> -            average_cpu: 1.0 + (squares_cpu / len as f64).sqrt(),
> -            highest_cpu: 1.0 + highest_cpu,
> -            average_memory: 1.0 + (squares_mem / len as f64).sqrt(),
> -            highest_memory: 1.0 + highest_mem,
> -        }
> +        [
> +            1.0 + (squares_cpu / len).sqrt(),
> +            1.0 + highest_cpu,
> +            1.0 + (squares_mem / len).sqrt(),
> +            1.0 + highest_mem,
> +        ]
>      }
>  
>      /// Returns the load imbalance among the nodes.
>      ///
> +    /// `cpu_weight`, respectively, `mem_weight`, control how much [`NodeStats::cpu_load`],
> +    /// respectively, [`NodeStats::mem_load`], contributes to the load imbalance via
> +    /// [`NodeStats::load`].

nit: can be documented in struct NodeStatsWeights

> +    ///
>      /// See [`calculate_node_imbalance`] for more information.
> -    pub fn node_imbalance(&self) -> f64 {
> -        calculate_node_imbalance(&self.nodes, |node| node.stats.load())
> +    pub fn node_imbalance(&self, cpu_weight: f64, mem_weight: f64) -> f64 {
> +        calculate_node_imbalance(&self.nodes, |node| node.stats.load(cpu_weight, mem_weight))
>      }

If we go the NodeStatsWeights route, then

    pub fn weighted_node_imbalance(&self, weights: &NodeStatsWeights) -> f64 {
        calculate_node_imbalance(&self.nodes, |node| node.stats.weighted_load(weights))
    }

    pub fn node_imbalance(&self) -> f64 {
        self.weighted_node_imbalance(NodeStatsWeights::default())
    }

So always using the idea that being able to set weights is the
generalized form and the old equal weights version of these methods is
a specialized variant.

>  
>      /// Returns the load imbalance among the nodes as if a specific resource was moved.
>      ///
> +    /// `cpu_weight`, respectively, `mem_weight`, control how much [`NodeStats::cpu_load`],
> +    /// respectively, [`NodeStats::mem_load`], contributes to the load imbalance via
> +    /// [`NodeStats::load`].

nit: can be documented in struct NodeStatsWeights

> +    ///
>      /// See [`calculate_node_imbalance`] for more information.
> -    fn node_imbalance_with_migration_candidate(&self, candidate: &MigrationCandidate) -> f64 {
> +    fn node_imbalance_with_migration_candidate(
> +        &self,
> +        candidate: &MigrationCandidate,
> +        cpu_weight: f64,
> +        mem_weight: f64,
> +    ) -> f64 {
>          calculate_node_imbalance(&self.nodes, |node| {
> -            node_stats_after_migration(candidate, node).load()
> +            node_stats_after_migration(candidate, node).load(cpu_weight, mem_weight)
>          })
>      }

same idea as above with weighted_node_imbalance()

>  
> -    /// Scores the given migration `candidates` by the best node imbalance improvement with
> -    /// exhaustive search.
> +    /// Uses brute-force search to score how much either of the given migration `candidates`
> +    /// improves node imbalance and ranks them accordingly.

Good catch!

As noted off-list, the "score" name is unfortunately a bit of a
misnomer, because this doesn't actually score them (the imbalance part
is only information for the feedback loop and log output outside), but
ranks them, therefore making the limit parameter reasonable.

However, as this is pre-existing and isn't relevant to this specific
patch, this should be done in a separate patch to not clutter this one,
which already changes quite a lot on its own.

This makes understanding past changes much easier in the future and
reviewing them too.

>      ///
>      /// The `candidates` are assumed to be consistent with the scheduler. No further validation is
>      /// done whether the given nodenames actually exist in the scheduler.
>      ///
>      /// The scoring is done as if each resource migration has already been done. This assumes that
>      /// the already migrated resource consumes the same amount of each stat as on the previous node
> -    /// according to its `stats`.
> +    /// according to its `stats`. The lower the score, the better.
> +    ///
> +    /// `cpu_weight` and `mem_weight` are blended into [`NodeStats::load`]. The higher the weight of
> +    /// a computational resource, the more the search will tend to prioritize balancing out that
> +    /// resource, e.g., a high `mem_weight` will steer migrations toward evening out memory usage,
> +    /// even at the cost of leaving CPU load less balanced. This is a general tendency, not a
> +    /// guarantee.
>      ///
>      /// Returns up to `limit` of the best scored migrations.
>      pub fn score_best_balancing_migration_candidates<I>(

same idea here with a

    weighted_score_best_balancing_migration_candidates()

>          &self,
>          candidates: I,
>          limit: usize,
> +        cpu_weight: usize,
> +        mem_weight: usize,

I'd be fine to use the NodeStatsWeights here as well for the weighted
version of this.

Even though it doesn't guarantee the non-negative integer property
anymore on the type level, that's up to the caller. However, we can
enforce this on the pve-rs side on the type level or with assertions
here and notes in the doc comment.

>      ) -> Vec<ScoredMigration>
>      where
>          I: IntoIterator<Item = MigrationCandidate>,
>      {
> +        let (w1, w2) = (cpu_weight as f64, mem_weight as f64);

nit: variable shadowing would probably be better here just for casting,
     but if you go for using the NodeStatsWeights struct here as well,
     this isn't needed anymore

> +
>          let mut scored_migrations = candidates
>              .into_iter()
>              .map(|candidate| {
> -                let imbalance = self.node_imbalance_with_migration_candidate(&candidate);
> +                let imbalance = self.node_imbalance_with_migration_candidate(&candidate, 1.0, 1.0);
> +                let score = self.node_imbalance_with_migration_candidate(&candidate, w1, w2);
>  
> -                Reverse(ScoredMigration::new(candidate, imbalance))
> +                Reverse(ScoredMigration::new(candidate, imbalance, score))
>              })
>              .collect::<BinaryHeap<_>>();
>  
> @@ -274,56 +294,106 @@ impl Scheduler {
>          best_migrations
>      }
>  
> -    /// Scores the given migration `candidates` by the best node imbalance improvement with the
> -    /// TOPSIS method.
> +    /// Scores the given migration `candidates` using the TOPSIS method.

Same here, should be in a separate patch as this was already true
beforehand. Both documentation changes for the score methods can be done
in one patch, of course.

>      ///
>      /// The `candidates` are assumed to be consistent with the scheduler. No further validation is
>      /// done whether the given nodenames actually exist in the scheduler.
>      ///
>      /// The scoring is done as if each resource migration has already been done. This assumes that
>      /// the already migrated resource consumes the same amount of each stat as on the previous node
> -    /// according to its `stats`.
> +    /// according to its `stats`. The lower the score, the better.
> +    ///
> +    /// The weights are assigned to the respective criteria of the TOPSIS method.
>      ///
>      /// Returns up to `limit` of the best scored migrations.
>      pub fn score_best_balancing_migration_candidates_topsis(

same for this method as above

>          &self,
>          candidates: &[MigrationCandidate],
>          limit: usize,
> +        cpu_weight: usize,
> +        mem_weight: usize,
>      ) -> Result<Vec<ScoredMigration>, Error> {
> +        let (w1, w2) = (cpu_weight as f64, mem_weight as f64);
> +
> +        let average_cpu = topsis::Criterion::new("average_cpu".to_owned(), -w1);
> +        let highest_cpu = topsis::Criterion::new(
> +            "highest_cpu".to_owned(),
> +            -(TOPSIS_AVERAGE_VS_HIGHEST_FACTOR * w1),
> +        );
> +        let average_mem = topsis::Criterion::new("average_mem".to_owned(), -w2);
> +        let highest_mem = topsis::Criterion::new(
> +            "highest_mem".to_owned(),
> +            -(TOPSIS_AVERAGE_VS_HIGHEST_FACTOR * w2),
> +        );
> +
>          let matrix = candidates
>              .iter()
>              .map(|candidate| {
>                  self.topsis_alternative_with(|node| node_stats_after_migration(candidate, node))
> -                    .into()
>              })
>              .collect::<Vec<_>>();
>  
> -        let best_alternatives =
> -            topsis::rank_alternatives(&topsis::Matrix::new(matrix)?, &PVE_HA_TOPSIS_CRITERIA)?;
> +        let mut scored_migrations = topsis::score_alternatives(
> +            &topsis::Matrix::new(matrix)?,
> +            &topsis::Criteria::new([average_cpu, highest_cpu, average_mem, highest_mem])?,
> +        )?
> +        .iter()
> +        .zip(candidates.iter())
> +        .map(|(topsis_score, candidate)| {
> +            let imbalance = self.node_imbalance_with_migration_candidate(candidate, w1, w2);

So the meaning of the 'imbalance' field in ScoredMigration would also
differ in meaning between brute force and TOPSIS?

> +
> +            Reverse(ScoredMigration::new(
> +                candidate.clone(),
> +                imbalance,
> +                // invert score for consistent sorting
> +                1.0 - topsis_score,
> +            ))
> +        })
> +        .collect::<BinaryHeap<_>>();
>  
> -        Ok(best_alternatives
> -            .into_iter()
> -            .take(limit)
> -            .map(|i| {
> -                let imbalance = self.node_imbalance_with_migration_candidate(&candidates[i]);
> +        let mut best_migrations = Vec::with_capacity(limit);
>  
> -                ScoredMigration::new(candidates[i].clone(), imbalance)
> -            })
> -            .collect())
> +        // BinaryHeap::into_iter_sorted() is still in nightly unfortunately
> +        while best_migrations.len() < limit {
> +            match scored_migrations.pop() {
> +                Some(Reverse(alternative)) => best_migrations.push(alternative),
> +                None => break,
> +            }
> +        }
> +
> +        Ok(best_migrations)
>      }

Hm, I think we should leave
score_best_balancing_migration_candidates_topsis() to only rank by
TOPSIS and not do the same procedure as is done with brute force.

Essentially this boils down to bruteforce and TOPSIS having different
guarantees in their return values, i.e., bruteforce will return a
Vec<ScoredMigration> with a monotonically increasing 'imbalance' value
while TOPSIS doesn't guarantee that but ranks after its own method.

The 'imbalance' value is then only used by external callers (i.e. the HA
Manager) to give users information and use it to decide whether the
migration is worth it with the 'margin' parameter.

>  
> -    /// Scores nodes to start a resource with the usage statistics `resource_stats` on.
> +    /// Scores nodes to start a resource with the usage statistics `resource_stats` on, using the
> +    /// TOPSIS method.

nit: ideally a separate patch

>      ///
>      /// The scoring is done as if the resource is already started on each node. This assumes that
>      /// the already started resource consumes the maximum amount of each stat according to its
>      /// `resource_stats`.
>      ///
> +    /// The weights are assigned to the respective criteria of the TOPSIS method.
> +    ///
>      /// Returns a vector of (nodename, score) pairs. Scores are between 0.0 and 1.0 and a higher
>      /// score is better.
>      pub fn score_nodes_to_start_resource<T: Into<ResourceStats>>(
>          &self,
>          resource_stats: T,
> +        cpu_weight: usize,
> +        mem_weight: usize,
>      ) -> Result<Vec<(String, f64)>, Error> {

Unrelated to this patch itself, but the parameters are exposed as
'ha-auto-rebalance-{cpu,mem}-weight', but here they are also used for
other kinds of load balancing, i.e., initial placement balancing.

So maybe we should change the name of those?

Otherwise, should get a weighted_ version as well.

> +        let (w1, w2) = (cpu_weight as f64, mem_weight as f64);
> +
> +        let average_cpu = topsis::Criterion::new("average_cpu".to_owned(), -w1);
> +        let highest_cpu = topsis::Criterion::new(
> +            "highest_cpu".to_owned(),
> +            -(TOPSIS_AVERAGE_VS_HIGHEST_FACTOR * w1),
> +        );
> +        let average_mem = topsis::Criterion::new("average_mem".to_owned(), -w2);
> +        let highest_mem = topsis::Criterion::new(
> +            "highest_mem".to_owned(),
> +            -(TOPSIS_AVERAGE_VS_HIGHEST_FACTOR * w2),
> +        );
> +
>          let resource_stats = resource_stats.into();
>  
>          let matrix = self
> @@ -339,12 +409,13 @@ impl Scheduler {
>  
>                      new_stats
>                  })
> -                .into()
>              })
>              .collect::<Vec<_>>();
>  
> -        let scores =
> -            topsis::score_alternatives(&topsis::Matrix::new(matrix)?, &PVE_HA_TOPSIS_CRITERIA)?;
> +        let scores = topsis::score_alternatives(
> +            &topsis::Matrix::new(matrix)?,
> +            &topsis::Criteria::new([average_cpu, highest_cpu, average_mem, highest_mem])?,
> +        )?;
>  
>          Ok(scores
>              .into_iter()
> @@ -367,6 +438,7 @@ mod tests {

Haven't reviewed the tests yet