On 01/04/2021 21:30, Valentin Schneider wrote: > During load-balance, groups classified as group_misfit_task are filtered > out if they do not pass > > group_smaller_max_cpu_capacity(<candidate group>, <local group>); > > which itself employs fits_capacity() to compare the sgc->max_capacity of > both groups. > > Due to the underlying margin, fits_capacity(X, 1024) will return false for > any X > 819. Tough luck, the capacity_orig's on e.g. the Pixel 4 are > {261, 871, 1024}. If a CPU-bound task ends up on one of those "medium" > CPUs, misfit migration will never intentionally upmigrate it to a CPU of > higher capacity due to the aforementioned margin. > > One may argue the 20% margin of fits_capacity() is excessive in the advent > of counter-enhanced load tracking (APERF/MPERF, AMUs), but one point here > is that fits_capacity() is meant to compare a utilization value to a > capacity value, whereas here it is being used to compare two capacity > values. As CPU capacity and task utilization have different dynamics, a > sensible approach here would be to add a new helper dedicated to comparing > CPU capacities. > > While at it, replace group_smaller_{min, max}_cpu_capacity() with > comparisons of the source group's min/max capacity and the destination > CPU's capacity.
IMHO, you haven't mentioned why you replace local sched group with dst CPU. I can see that only the capacity of the dst CPU makes really sense here. Might be worth mentioning in the patch header why. There is some of it in v3 6/7 but that's a different change. Reviewed-by: Dietmar Eggemann <dietmar.eggem...@arm.com> [...]