All of lore.kernel.org
 help / color / mirror / Atom feed
From: Valentin Schneider <valentin.schneider@arm.com>
To: Mel Gorman <mgorman@techsingularity.net>
Cc: Vincent Guittot <vincent.guittot@linaro.org>,
	Ingo Molnar <mingo@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	pauld@redhat.com, srikar@linux.vnet.ibm.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 v2
Date: Fri, 20 Dec 2019 15:32:53 +0000	[thread overview]
Message-ID: <726b8216-6334-585e-3996-175e9a51df36@arm.com> (raw)
In-Reply-To: <20191220142239.GM3178@techsingularity.net>

On 20/12/2019 14:22, Mel Gorman wrote:
>> Now, I have to say I'm not sold on the idle_cpus thing, I'd much rather use
>> the number of runnable tasks. We are setting up a threshold for how far we
>> are willing to ignore imbalances; if we have overloaded CPUs we *really*
>> should try to solve this. Number of tasks is the safer option IMO: when we
>> do have one task per CPU, it'll be the same as if we had used idle_cpus, and
>> when we don't have one task per CPU we'll load-balance more often that we
>> would have with idle_cpus.
>>
> 
> I couldn't convince myself to really push back hard on the sum_nr_runnable
> versus idle_cpus.  If the local group has spare capacity and the busiest
> group has multiple tasks stacked on CPUs then it's most likely due to
> CPU affinity.

Not necessarily, for instance wakeup balancing (select_idle_sibling()) could
end up packing stuff within a node if said node spans more than one LLC
domain, which IIRC is the case on some AMD chips.

Or, still with the same LLC < node topology, you could start with the node
being completely utilized, then some tasks on some LLC domains terminate but
there's an LLC that still has a bunch of tasks running, and then you're left
with an imbalance between LLC domains that the wakeup balance cannot solve.

> In that case, there is no guarantee tasks can move to the
> local group either. In that case, the difference between sum_nr_running
> and idle_cpus is almost moot.  There may be common use cases where the
> distinction really matters but right now, I'm at the point where I think
> such a change could be a separate patch with the use case included and
> supporting data on why it must be sum_nr_running.  Right now, I feel it's
> mostly a cosmetic issue given the context and intent of the patch.
> 

Let me spin it this way: do we need to push this ignoring of the imbalance
as far as possible, or are we okay with it only happening when there's just a
few tasks running? The latter is achieved with sum_nr_running and is the
safer option IMO.

  reply	other threads:[~2019-12-20 15:33 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-20  8:42 [PATCH] sched, fair: Allow a small degree of load imbalance between SD_NUMA domains v2 Mel Gorman
2019-12-20 12:40 ` Valentin Schneider
2019-12-20 14:22   ` Mel Gorman
2019-12-20 15:32     ` Valentin Schneider [this message]
2019-12-21 11:25   ` Mel Gorman
2019-12-22 12:00 ` Srikar Dronamraju
2019-12-23 13:31 ` Vincent Guittot
2019-12-23 13:41   ` Vincent Guittot
2020-01-03 14:31   ` Mel Gorman
2020-01-06 13:55     ` Vincent Guittot
2020-01-06 14:52       ` Mel Gorman
2020-01-07  8:38         ` Vincent Guittot
2020-01-07  9:56           ` Mel Gorman
2020-01-07 11:17             ` Vincent Guittot
2020-01-07 11:56               ` Mel Gorman
2020-01-07 16:00                 ` Vincent Guittot
2020-01-07 20:24                   ` Mel Gorman
2020-01-08  8:25                     ` Vincent Guittot
2020-01-08  8:49                       ` Mel Gorman
2020-01-08 13:18                     ` Peter Zijlstra
2020-01-08 14:03                       ` Mel Gorman
2020-01-08 16:46                         ` Vincent Guittot
2020-01-08 18:03                           ` Mel Gorman
2020-01-07 11:22             ` Peter Zijlstra
2020-01-07 11:42               ` Mel Gorman
2020-01-07 12:29                 ` Peter Zijlstra
2020-01-07 12:28               ` Peter Zijlstra
2020-01-07 19:26             ` Phil Auld

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=726b8216-6334-585e-3996-175e9a51df36@arm.com \
    --to=valentin.schneider@arm.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=srikar@linux.vnet.ibm.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.