Messages in this thread | | | Date | Wed, 6 Jun 2018 05:55:29 -0700 | From | Srikar Dronamraju <> | Subject | Re: [PATCH 16/19] sched/numa: Detect if node actively handling migration |
| |
> > > > I thought about this. Lets say we evaluated that destination node can > > allow movement. While we iterate through the list of cpus trying to > > find > > the best cpu node, we find a idle cpu towards the end of the list. > > However if another task as already raced with us to move a task to > > this > > node, then we should bail out. Keeping the check in task_numa_compare > > will allow us to do this. > > Your check is called once for every invocation > of task_numa_compare. It does not matter whether > it is inside or outside, except on the outside > the variable manipulation will be easier to read. >
Okay I mistook your comment; Basically you want the check to be moved within the for-loop in task_numa_find_cpu. I will do the needful.
> > > > 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.
| |