linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Mel Gorman <mgorman@techsingularity.net>,
	Ingo Molnar <mingo@kernel.org>, Rik van Riel <riel@surriel.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 4/4] sched/numa: Do not move imbalanced load purely on the basis of an idle CPU
Date: Fri, 7 Sep 2018 19:12:01 +0530	[thread overview]
Message-ID: <20180907134201.GC3995@linux.vnet.ibm.com> (raw)
In-Reply-To: <20180907124432.GN24082@hirez.programming.kicks-ass.net>

* Peter Zijlstra <peterz@infradead.org> [2018-09-07 14:44:32]:

> On Fri, Sep 07, 2018 at 01:37:39PM +0100, Mel Gorman wrote:
> > On Fri, Sep 07, 2018 at 01:33:09PM +0200, Peter Zijlstra wrote:
> > > > ---
> > > >  kernel/sched/fair.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > > > index d59d3e00a480..d4c289c11012 100644
> > > > --- a/kernel/sched/fair.c
> > > > +++ b/kernel/sched/fair.c
> > > > @@ -1560,7 +1560,7 @@ static bool task_numa_compare(struct task_numa_env *env,
> > > >  		goto unlock;
> > > >  
> > > >  	if (!cur) {
> > > > -		if (maymove || imp > env->best_imp)
> > > > +		if (maymove)
> > > >  			goto assign;
> > > >  		else
> > > >  			goto unlock;
> > > 
> > > Srikar's patch here:
> > > 
> > >   http://lkml.kernel.org/r/1533276841-16341-4-git-send-email-srikar@linux.vnet.ibm.com
> > > 
> > > Also frobs this condition, but in a less radical way. Does that yield
> > > similar results?
> > 
> > I can check. I do wonder of course if the less radical approach just means
> > that automatic NUMA balancing and the load balancer simply disagree about
> > placement at a different time. It'll take a few days to have an answer as
> > the battery of workloads to check this take ages.
> 
> Yeah, I was afraid it would.. Srikar, can you also evaluate, I suspect
> we'll have to pick one of these two patches.

I can surely run some benchmarks between the two patches.
However comparing  Mel's patch with
http://lkml.kernel.org/r/1533276841-16341-4-git-send-email-srikar@linux.vnet.ibm.com

Mel's patch

  	if (!cur) {
 -		if (maymove || imp > env->best_imp)
 +		if (maymove)
  			goto assign;
  		else
http://lkml.kernel.org/r/1533276841-16341-4-git-send-email-srikar@linux.vnet.ibm.com


 	if (!cur) {
-		if (maymove || imp > env->best_imp)
+		if (maymove && moveimp >= env->best_imp)
 			goto assign;
 		else

In Mel's fix, if we already found a candidate task to swap and then encounter a
idle cpu, we are going ahead and overwriting the swap candidate. There is
always a chance that swap candidate is a better fit than moving to idle cpu.

In the patch which is in your queue, we are saying move only if it is better than
swap candidate. So this is noway less radical than Mel's patch and probably
more correct.

-- 
Thanks and Regards
Srikar Dronamraju
> 


  reply	other threads:[~2018-09-07 13:42 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-07 10:11 [PATCH 0/4] Follow-up fixes for v4.19-rc1 NUMA balancing Mel Gorman
2018-09-07 10:11 ` [PATCH 1/4] sched/numa: Remove redundant numa_stats nr_running field Mel Gorman
2018-09-07 10:11 ` [PATCH 2/4] sched/numa: Remove unused calculations in update_numa_stats Mel Gorman
2018-09-07 10:11 ` [PATCH 3/4] sched/numa: Stop comparing tasks for NUMA placement after selecting an idle core Mel Gorman
2018-09-07 13:05   ` Srikar Dronamraju
2018-09-07 14:20     ` Mel Gorman
2018-09-07 10:11 ` [PATCH 4/4] sched/numa: Do not move imbalanced load purely on the basis of an idle CPU Mel Gorman
2018-09-07 11:33   ` Peter Zijlstra
2018-09-07 12:37     ` Mel Gorman
2018-09-07 12:44       ` Peter Zijlstra
2018-09-07 13:42         ` Srikar Dronamraju [this message]
2018-09-07 14:28           ` Mel Gorman
2018-09-10  9:41       ` Mel Gorman
2018-09-12  6:54         ` Srikar Dronamraju
2018-09-12  9:36           ` Peter Zijlstra
2018-09-12 10:45             ` Srikar Dronamraju
2018-09-12  9:57           ` Ingo Molnar
2018-09-12 10:27             ` Srikar Dronamraju
2018-09-12 10:57             ` Mel Gorman
2018-09-12 10:52           ` Mel Gorman
2018-09-07 11:24 ` [PATCH 0/4] Follow-up fixes for v4.19-rc1 NUMA balancing Peter Zijlstra
2018-09-07 12:29   ` Mel Gorman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180907134201.GC3995@linux.vnet.ibm.com \
    --to=srikar@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@techsingularity.net \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=riel@surriel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).