All of lore.kernel.org
 help / color / mirror / Atom feed
From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Mel Gorman <mgorman@techsingularity.net>,
	Ingo Molnar <mingo@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	pauld@redhat.com, valentin.schneider@arm.com,
	quentin.perret@arm.com, dietmar.eggemann@arm.com,
	Morten.Rasmussen@arm.com, hdanton@sina.com, parth@linux.ibm.com,
	riel@surriel.com, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] sched, fair: Allow a small degree of load imbalance between SD_NUMA domains
Date: Fri, 20 Dec 2019 18:30:56 +0530	[thread overview]
Message-ID: <20191220130056.GA13192@linux.vnet.ibm.com> (raw)
In-Reply-To: <20191219144539.GA19614@linaro.org>

* Vincent Guittot <vincent.guittot@linaro.org> [2019-12-19 15:45:39]:

> Hi Mel,
> 
> Thanks for looking at this NUMA locality vs spreading tasks point.
> 
> 
> Shouldn't you consider the number of busiest->idle_cpus instead of the busiest->sum_nr_running ?
> and you could simplify by 
> 
> 
> 	if ((env->sd->flags & SD_NUMA) &&
> 		((100 * busiest->group_weight) <= (env->sd->imbalance_pct * (busiest->idle_cpus << 1)))) {
> 			env->imbalance = 0;
> 			return;
> 	}

Are idle_cpus and sum_nr_running good enough metrics to look at a NUMA
level? We could have asymmetric NUMA topology where one DIE/MC/groups may
have more cores than the other. In such a case looking at idle_cpus (or
sum_nr_running) of the group may not always lead us to the right load
balancing solution.


-- 
Thanks and Regards
Srikar Dronamraju


      parent reply	other threads:[~2019-12-20 13:01 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-18 15:44 [PATCH] sched, fair: Allow a small degree of load imbalance between SD_NUMA domains Mel Gorman
2019-12-18 18:50 ` Valentin Schneider
2019-12-18 22:50   ` Mel Gorman
2019-12-19 11:56     ` Valentin Schneider
2019-12-19 10:02   ` Peter Zijlstra
2019-12-19 11:46     ` Valentin Schneider
2019-12-19 14:23       ` Valentin Schneider
2019-12-19 15:23     ` Mel Gorman
2019-12-18 18:54 ` Valentin Schneider
2019-12-19  2:58 ` Rik van Riel
2019-12-19  8:41   ` Mel Gorman
2019-12-19 10:04 ` Peter Zijlstra
2019-12-19 14:45 ` Vincent Guittot
2019-12-19 15:16   ` Valentin Schneider
2019-12-19 15:18   ` Mel Gorman
2019-12-19 15:41     ` Vincent Guittot
2019-12-19 15:58       ` Mel Gorman
2019-12-20 13:00   ` Srikar Dronamraju [this message]

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=20191220130056.GA13192@linux.vnet.ibm.com \
    --to=srikar@linux.vnet.ibm.com \
    --cc=Morten.Rasmussen@arm.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=hdanton@sina.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@techsingularity.net \
    --cc=mingo@kernel.org \
    --cc=parth@linux.ibm.com \
    --cc=pauld@redhat.com \
    --cc=peterz@infradead.org \
    --cc=quentin.perret@arm.com \
    --cc=riel@surriel.com \
    --cc=valentin.schneider@arm.com \
    --cc=vincent.guittot@linaro.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.