All of lore.kernel.org
 help / color / mirror / Atom feed
From: Preeti U Murthy <preeti@linux.vnet.ibm.com>
To: Morten Rasmussen <morten.rasmussen@arm.com>
Cc: "peterz@infradead.org" <peterz@infradead.org>,
	"mingo@kernel.org" <mingo@kernel.org>,
	"riel@redhat.com" <riel@redhat.com>,
	"daniel.lezcano@linaro.org" <daniel.lezcano@linaro.org>,
	"vincent.guittot@linaro.org" <vincent.guittot@linaro.org>,
	"srikar@linux.vnet.ibm.com" <srikar@linux.vnet.ibm.com>,
	"pjt@google.com" <pjt@google.com>,
	"benh@kernel.crashing.org" <benh@kernel.crashing.org>,
	"efault@gmx.de" <efault@gmx.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"iamjoonsoo.kim@lge.com" <iamjoonsoo.kim@lge.com>,
	"svaidy@linux.vnet.ibm.com" <svaidy@linux.vnet.ibm.com>,
	"tim.c.chen@linux.intel.com" <tim.c.chen@linux.intel.com>,
	"jason.low2@hp.com" <jason.low2@hp.com>
Subject: Re: [PATCH V2] sched: Improve load balancing in the presence of idle CPUs
Date: Fri, 27 Mar 2015 22:16:30 +0530	[thread overview]
Message-ID: <55158966.4050300@linux.vnet.ibm.com> (raw)
In-Reply-To: <20150327143839.GO18994@e105550-lin.cambridge.arm.com>

Hi Morten,

On 03/27/2015 08:08 PM, Morten Rasmussen wrote:
> Hi Preeti,
> 
> On Thu, Mar 26, 2015 at 01:02:44PM +0000, Preeti U Murthy wrote:
>> Fix this, by checking if a CPU was woken up to do nohz idle load
>> balancing, before it does load balancing upon itself. This way we allow
>> idle CPUs across the system to do load balancing which results in
>> quicker spread of load, instead of performing load balancing within the
>> local sched domain hierarchy of the ILB CPU alone under circumstances
>> such as above.
>>
>> Signed-off-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
>> ---
>> Changes from V1:
>> 1. Added relevant comments
>> 2. Wrapped lines to a fixed width in the changelog
>>
>>  kernel/sched/fair.c |    8 +++++---
>>  1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index bcfe320..8b6d0d5 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -7660,14 +7660,16 @@ static void run_rebalance_domains(struct softirq_action *h)
>>  	enum cpu_idle_type idle = this_rq->idle_balance ?
>>  						CPU_IDLE : CPU_NOT_IDLE;
>>  
>> -	rebalance_domains(this_rq, idle);
>> -
>>  	/*
>>  	 * If this cpu has a pending nohz_balance_kick, then do the
>>  	 * balancing on behalf of the other idle cpus whose ticks are
>> -	 * stopped.
>> +	 * stopped. Do nohz_idle_balance *before* rebalance_domains to
>> +	 * give the idle cpus a chance to load balance. Else we may
>> +	 * load balance only within the local sched_domain hierarchy
>> +	 * and abort nohz_idle_balance altogether if we pull some load.
>>  	 */
>>  	nohz_idle_balance(this_rq, idle);
>> +	rebalance_domains(this_rq, idle);
> 
> IIUC, this change means that you will always wake up one more cpu than
> necessary unless you have enough work for all cpus in the system. For
> example, cpu0 is busy with two tasks and cpu1+2 are nohz_idle. cpu0
> kicks cpu1 to do a nohz_idle_balance(). With the change it will balance
> on behalf of cpu2 first and pull one of the tasks from cpu0. When done
> with nohz_idle_balance() cpu1 has nothing left to pull when balancing
> itself and goes back to sleep.
> 
> My concern is that this will increase the number of cpu wakeups quite
> significantly. Am I missing something?

Its true that we wakeup all idle CPUs. But I think we are justified in
doing so, given that nohz_idle_balance() was deemed necessary. The logic
behind nohz_idle_balance() as I see it is that, all idle CPUs should be
brought to action when some scheduling group is found to be busy. With
the current code that does not happen if one of them happen to pull
tasks. This logic does not make sense to me.

With the current code, I think it is hard to estimate how many idle CPU
wakeups would be sufficient to balance out the system load. But I
certainly feel that waking up all of them to perform the load balancing
that was asked for, is far better than waking up none of them. This is
in favor of performance. I agree the extra wakeups would do us harm with
power savings, but I would still be fine with it, given the undesirable
scenario that occurs as a consequence, as described in the changelog.

Regards
Preeti U Murthy
> 
> Morten
> 


  reply	other threads:[~2015-03-27 16:46 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-26 13:02 [PATCH V2] sched: Improve load balancing in the presence of idle CPUs Preeti U Murthy
2015-03-26 17:03 ` Jason Low
2015-03-27  2:12 ` Wanpeng Li
2015-03-27  4:33   ` Preeti U Murthy
2015-03-27  4:23     ` Wanpeng Li
2015-03-27  5:01     ` Jason Low
2015-03-27  5:07   ` Jason Low
2015-03-27  5:39     ` Srikar Dronamraju
2015-03-27  7:00       ` Wanpeng Li
2015-03-27  6:43     ` Wanpeng Li
2015-03-27 16:23     ` Preeti U Murthy
2015-03-27 11:43 ` [tip:sched/core] " tip-bot for Preeti U Murthy
2015-03-27 13:03 ` [PATCH V2] " Srikar Dronamraju
2015-03-27 14:38 ` Morten Rasmussen
2015-03-27 16:46   ` Preeti U Murthy [this message]
2015-03-27 17:56     ` Morten Rasmussen
2015-03-30  7:26       ` Preeti U Murthy
2015-03-30 11:30         ` Morten Rasmussen
2015-03-30 11:06       ` Peter Zijlstra
2015-03-30 12:03         ` Morten Rasmussen
2015-03-30 12:24           ` Peter Zijlstra
2015-03-30 12:54             ` Peter Zijlstra
2015-03-30 13:29             ` Vincent Guittot
2015-03-30 14:01               ` Peter Zijlstra
2015-03-30 15:27               ` Morten Rasmussen
2015-03-31  8:58           ` Preeti U Murthy
2015-03-31 17:30             ` Jason Low
2015-04-01  6:28               ` Preeti U Murthy
2015-04-01 13:03                 ` Morten Rasmussen
2015-04-02  0:55                   ` Jason Low
2015-04-02  3:22                   ` Preeti U Murthy
2015-03-30 13:45 ` Vincent Guittot
2015-03-31  8:06   ` Preeti U Murthy

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=55158966.4050300@linux.vnet.ibm.com \
    --to=preeti@linux.vnet.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=efault@gmx.de \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=jason.low2@hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=morten.rasmussen@arm.com \
    --cc=peterz@infradead.org \
    --cc=pjt@google.com \
    --cc=riel@redhat.com \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=svaidy@linux.vnet.ibm.com \
    --cc=tim.c.chen@linux.intel.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.