Re: [PATCH v2 00/19] Fixes for sched/numa_balancing

From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Mel Gorman <mgorman@techsingularity.net>,
	Rik van Riel <riel@surriel.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH v2 00/19]  Fixes for sched/numa_balancing
Date: Mon, 23 Jul 2018 09:29:54 -0700	[thread overview]
Message-ID: <20180723162954.GA2699@linux.vnet.ibm.com> (raw)
In-Reply-To: <20180723152147.GE2494@hirez.programming.kicks-ass.net>

* Peter Zijlstra <peterz@infradead.org> [2018-07-23 17:21:47]:

> On Mon, Jul 23, 2018 at 08:09:55AM -0700, Srikar Dronamraju wrote:
> 
> > > >   sched/numa: Stop multiple tasks from moving to the cpu at the same time
> > 
> > This patch has go-ahead from Mel and Rik and no outstanding comments.
> 
> I left it out because it's part of the big xchg() mess.
> 
> In particular:
> 
> +       if (xchg(&rq->numa_migrate_on, 1))
> +               return;
> +
> +       if (env->best_cpu != -1) {
> +               rq = cpu_rq(env->best_cpu);
> +               WRITE_ONCE(rq->numa_migrate_on, 0);
> +       }
> 
> I'm again confused by clearing numa_migrate_on at this point..

First task choose a cpu to swap/migrate, sets the cpu to best_cpu and
also numa_migrate_on.  Next it finds a better cpu to swap/move. Now if
the task is able to move to the better cpu, then it should clear
numa_migrate_on on the previous best_cpu.

If we dont reset numa_migrate_on on finding a better cpu, the
numa_migrate_on stays set for the previous cpu, causing previous cpu to
never be a target of numa balance.

> 
> > > >   sched/numa: Updation of scan period need not be in lock
> > 
> > I didnt see any comments for this apart from an ack from Rik.
> > + It thought it was trivial and shouldnt have any side-effect.
> 
> Oh, my bad I actually have this one.
> 