All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Shi <alex.shi@intel.com>
To: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>,
	Mike Galbraith <bitbucket@online.de>,
	Matthew Garrett <mjg59@srcf.ucam.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"svaidy@linux.vnet.ibm.com" <svaidy@linux.vnet.ibm.com>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Amit Kucheria <amit.kucheria@linaro.org>,
	Morten Rasmussen <Morten.Rasmussen@arm.com>,
	Paul McKenney <paul.mckenney@linaro.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Arjan van de Ven <arjan@linux.intel.com>,
	Ingo Molnar <mingo@kernel.org>, Paul Turner <pjt@google.com>,
	Venki Pallipadi <venki@google.com>,
	Robin Randhawa <robin.randhawa@arm.com>,
	Lists linaro-dev <linaro-dev@lists.linaro.org>
Subject: Re: sched: Consequences of integrating the Per Entity Load Tracking Metric into the Load Balancer
Date: Sun, 20 Jan 2013 23:30:57 +0800	[thread overview]
Message-ID: <50FC0DB1.6050605@intel.com> (raw)
In-Reply-To: <50ECE097.7010609@linux.vnet.ibm.com>

On 01/09/2013 11:14 AM, Preeti U Murthy wrote:
>>>>> Here comes the point of making both load balancing and wake up
>>>>> balance(select_idle_sibling) co operative. How about we always schedule
>>>>> the woken up task on the prev_cpu? This seems more sensible considering
>>>>> load balancing considers blocked load as being a part of the load of cpu2.
>>>>
>>>> Hi Preeti,
>>>>
>>>> I'm not sure that we want such steady state at cores level because we
>>>> take advantage of migrating wake up tasks between cores that share
>>>> their cache as Matthew demonstrated. But I agree that reaching such
>>>> steady state at cluster and CPU level is interesting.
>>>>
>>>> IMHO, you're right that taking the blocked load into consideration
>>>> should minimize tasks migration between cluster but it should no
>>>> prevent fast task migration between cores that share their cache
>>>
>>> True Vincent.But I think the one disadvantage even at cpu or cluster
>>> level is that when we consider blocked load, we might prevent any more
>>> tasks from being scheduled on that cpu during periodic load balance if
>>> the blocked load is too much.This is very poor cpu utilization
>>
>> The blocked load of a cluster will be high if the blocked tasks have
>> run recently. The contribution of a blocked task will be divided by 2
>> each 32ms, so it means that a high blocked load will be made of recent
>> running tasks and the long sleeping tasks will not influence the load
>> balancing.
>> The load balance period is between 1 tick (10ms for idle load balance
>> on ARM) and up to 256 ms (for busy load balance) so a high blocked
>> load should imply some tasks that have run recently otherwise your
>> blocked load will be small and will not have a large influence on your
>> load balance

Just tried using cfs's runnable_load_avg + blocked_load_avg in
weighted_cpuload() with my v3 patchset, aim9 shared workfile testing
show the performance dropped 70% more on the NHM EP machine. :(

  reply	other threads:[~2013-01-20 15:31 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-02  4:22 sched: Consequences of integrating the Per Entity Load Tracking Metric into the Load Balancer Preeti U Murthy
2013-01-02  8:12 ` Mike Galbraith
2013-01-03 10:38   ` Preeti U Murthy
2013-01-03 20:06     ` Mike Galbraith
2013-01-04 11:41     ` Mike Galbraith
2013-01-05  8:13     ` Mike Galbraith
2013-01-06 16:32       ` Mike Galbraith
2013-01-07  5:29         ` Preeti U Murthy
2013-01-07  7:36           ` Mike Galbraith
2013-01-08  8:41             ` Preeti U Murthy
2013-01-16 14:08               ` Alex Shi
2013-01-17  5:17                 ` Namhyung Kim
2013-01-17 10:16                   ` Preeti U Murthy
2013-01-17 13:41                   ` Alex Shi
2013-01-24  3:13                     ` Alex Shi
2013-01-17  8:45                 ` Preeti U Murthy
2013-01-07 15:48 ` Vincent Guittot
2013-01-08  6:06   ` Preeti U Murthy
2013-01-08 14:04     ` Vincent Guittot
2013-01-09  3:14       ` Preeti U Murthy
2013-01-20 15:30         ` Alex Shi [this message]
2013-01-20 15:52           ` Alex Shi
2013-01-21  2:40             ` Preeti U Murthy
2013-01-21  3:26               ` Alex Shi

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=50FC0DB1.6050605@intel.com \
    --to=alex.shi@intel.com \
    --cc=Morten.Rasmussen@arm.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=amit.kucheria@linaro.org \
    --cc=arjan@linux.intel.com \
    --cc=bitbucket@online.de \
    --cc=linaro-dev@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mjg59@srcf.ucam.org \
    --cc=paul.mckenney@linaro.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=pjt@google.com \
    --cc=preeti@linux.vnet.ibm.com \
    --cc=robin.randhawa@arm.com \
    --cc=svaidy@linux.vnet.ibm.com \
    --cc=venki@google.com \
    --cc=vincent.guittot@linaro.org \
    --cc=viresh.kumar@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.