Why util**3 when calculating util score in autoscaler?

harryge00 · December 13, 2021, 3:40am

ray-project/ray/blob/master/python/ray/autoscaler/_private/resource_demand_scheduler.py#L805

    
      
          num_matching_resource_types = 0
          for k, v in node_resources.items():
              # Don't divide by zero.
              if v < 1:
                  # Could test v == 0 on the nose, but v < 1 feels safer.
                  # (Note that node resources are integers.)
                  continue
              if k in resource_types:
                  num_matching_resource_types += 1
              util = (v - remaining[k]) / v
              util_by_resources.append(v * (util**3))
          
          
# Could happen if node_resources has only zero values.
          if not util_by_resources:
              return None
          
          
# Prioritize matching multiple resource types first, then prioritize
          # using all resources, then prioritize overall balance
          # of multiple resources.
          return (num_matching_resource_types, min(util_by_resources),
                  np.mean(util_by_resources))

Here, we use v * (util**3) to calculate a node’s utilization score. I was wondering why util ** 3.
Any document to explain that?

harryge00 · January 11, 2022, 6:35am

@ericl sorry to bother you. I was wondering why not just use util or util ** 2 as score?

Dmitri · January 11, 2022, 7:07pm

Cc also @Alex, I think I recall you or @ericl explaining this once, but I forgot.

Dmitri · January 12, 2022, 9:58pm

I took another look at the score, which is

v * u^3

where v is the node’s total resource quantity and u is the utilization fraction.

Will try to conceptualize this. We could equivalently rank by the cube root of the expression above

v^(1/3) * u

That’s utilization times a slowly growing factor of the node’s size. 3, as opposed to 2 or 4, is to-taste.

So we care most about utilization, but we give a slight preference to larger nodes that will do a better job of satisfying resource requests.

The idea of preferring nodes that will fulfill more of the resource demands also motivated a recent change to the ranking strategy that favors nodes that satisfy /more resource types/.

github.com

ray-project/ray/blob/13f20e5e1ea0c98266a039034a9e570e3658410c/python/ray/autoscaler/_private/resource_demand_scheduler.py#L811

    
      
                      continue
                  if k in resource_types:
                      num_matching_resource_types += 1
                  util = (v - remaining[k]) / v
                  util_by_resources.append(v * (util**3))
          
          
    # Could happen if node_resources has only zero values.
              if not util_by_resources:
                  return None
          
          
    # Prioritize matching multiple resource types first, then prioritize
              # using all resources, then prioritize overall balance
              # of multiple resources.
              return (num_matching_resource_types, min(util_by_resources),
                      np.mean(util_by_resources))
          
          

          
def get_bin_pack_residual(node_resources: List[ResourceDict],
                                    resource_demands: List[ResourceDict],
                                    strict_spread: bool = False
                                    ) -> (List[ResourceDict], List[ResourceDict]):