On Wed, 2018-06-06 at 05:55 -0700, Srikar Dronamraju wrote: > > > > > > While we can't complete avoid this, the second check will try to > > > make > > > sure we don't hop on/hop off just for small incremental numa > > > improvement. > > > > However, all those racing tasks start searching > > the CPUs on a node from the same start position. > > > > That means they may all get stuck on the same > > task/cpu A, and not select the better task/cpu B. > > > > What am I missing? > > All tasks will not be stuck at task/cpu A. > > "[PATCH 10/19] sched/numa: Stop multiple tasks from moving to the > cpu..." the first task to set cpu A as swap target will ensure > subsequent tasks wont be allowed to set cpu A as target for swap till > it > finds a better task/cpu. Because of this there a very very small > chance > of a second task unable to find a task to swap.
Would it not be better for task_numa_compare to skip from consideration CPUs that somebody else is already trying to migrate a task to, but still search for the best location, instead of settling for a worse location to migrate to? -- All Rights Reversed.
signature.asc
Description: This is a digitally signed message part
