On Wed, 2018-06-06 at 08:32 -0700, Srikar Dronamraju wrote:
> Yes its better to skip cpus if they are already in migration.
> And we are already doing it with the above patch. However as I said
> earlier
>
> - Task T1 sets Cpu 1 as best_cpu,
> - Task T2 finds cpu1 and skips Cpu1
> - Task T1 fin
> >
> > 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/
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
> >
> > 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
On Mon, 2018-06-04 at 20:56 -0700, Srikar Dronamraju wrote:
> * Rik van Riel [2018-06-04 16:05:55]:
>
> > On Mon, 2018-06-04 at 15:30 +0530, Srikar Dronamraju wrote:
> >
> > > @@ -1554,6 +1562,9 @@ static void task_numa_compare(struct
> > > task_numa_env *env,
> > > if (READ_ONCE(dst_rq->numa_
* Rik van Riel [2018-06-04 16:05:55]:
> On Mon, 2018-06-04 at 15:30 +0530, Srikar Dronamraju wrote:
>
> > @@ -1554,6 +1562,9 @@ static void task_numa_compare(struct
> > task_numa_env *env,
> > if (READ_ONCE(dst_rq->numa_migrate_on))
> > return;
> >
> > + if (*move && READ_ONC
On Mon, 2018-06-04 at 15:30 +0530, Srikar Dronamraju wrote:
> @@ -1554,6 +1562,9 @@ static void task_numa_compare(struct
> task_numa_env *env,
> if (READ_ONCE(dst_rq->numa_migrate_on))
> return;
>
> + if (*move && READ_ONCE(pgdat->active_node_migrate))
> + *mo
If a node is the destination for a task migration under numa balancing,
then any parallel movements to the node will be restricted. In such a
scenario, detect at the earliest and avoid evaluation for a task
movement.
While here, avoid task migration if the numa imbalance is very minimal.
Especiall
8 matches
Mail list logo