public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
To: Peter Williams <pwil3058@bigpond.net.au>
Cc: Andrew Morton <akpm@osdl.org>,
	"Chen, Kenneth W" <kenneth.w.chen@intel.com>,
	Con Kolivas <kernel@kolivas.org>, Ingo Molnar <mingo@elte.hu>,
	Mike Galbraith <efault@gmx.de>,
	Nick Piggin <nickpiggin@yahoo.com.au>,
	"Siddha, Suresh B" <suresh.b.siddha@intel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] sched: move enough load to balance average load per task
Date: Mon, 10 Apr 2006 18:12:37 -0700	[thread overview]
Message-ID: <20060410181237.A26977@unix-os.sc.intel.com> (raw)
In-Reply-To: <4439FF0C.8030407@bigpond.net.au>; from pwil3058@bigpond.net.au on Mon, Apr 10, 2006 at 04:45:32PM +1000

On Mon, Apr 10, 2006 at 04:45:32PM +1000, Peter Williams wrote:
> Problem:
> 
> The current implementation of find_busiest_group() recognizes that 
> approximately equal average loads per task for each group/queue are 
> desirable (e.g. this condition will increase the probability that the 
> top N highest priority tasks on an N CPU system will be on different 
> CPUs) by being slightly more aggressive when *imbalance is small but the 
> average load per task in "busiest" group is more than that in "this" 
> group.  Unfortunately, the amount moved from "busiest" to "this" is too 
> small to reduce the average load per task on "busiest" (at best there 
> will be no change and at worst it will get bigger).

Peter, We don't need to reduce the average load per task on "busiest"
always. By moving a "busiest_load_per_task", we will increase the 
average load per task of lesser busy cpu (there by trying to achieve
the equality with busiest...)

Can you give an example scenario where this patch helps? And doesn't
the normal imabalance calculations capture those issues?

thanks,
suresh

> 
> Solution:
> 
> Increase the amount of load moved from "busiest" to "this" in these 
> circumstances while making sure that the amount of load moved won't 
> increase the (absolute) difference in the two groups' total weighted 
> loads.  A task with a weighted load greater than the average needs to be 
> moved to cause the average to be reduced.
> 
> NB This makes no difference to load balancing for the case where all 
> tasks have nice==0.
> 
> Signed-off-by: Peter Williams <pwil3058@bigpond.com.au>
> 
> -- 
> Peter Williams                                   pwil3058@bigpond.net.au
> 
> "Learning, n. The kind of ignorance distinguishing the studious."
>   -- Ambrose Bierce

> Index: MM-2.6.17-rc1-mm2/kernel/sched.c
> ===================================================================
> --- MM-2.6.17-rc1-mm2.orig/kernel/sched.c	2006-04-10 10:46:53.000000000 +1000
> +++ MM-2.6.17-rc1-mm2/kernel/sched.c	2006-04-10 14:16:32.000000000 +1000
> @@ -2258,16 +2258,20 @@ find_busiest_group(struct sched_domain *
>  	if (*imbalance < busiest_load_per_task) {
>  		unsigned long pwr_now = 0, pwr_move = 0;
>  		unsigned long tmp;
> -		unsigned int imbn = 2;
>  
> -		if (this_nr_running) {
> +		if (this_nr_running)
>  			this_load_per_task /= this_nr_running;
> -			if (busiest_load_per_task > this_load_per_task)
> -				imbn = 1;
> -		} else
> +		else
>  			this_load_per_task = SCHED_LOAD_SCALE;
>  
> -		if (max_load - this_load >= busiest_load_per_task * imbn) {
> +		if (busiest_load_per_task > this_load_per_task) {
> +			unsigned long dld = max_load - this_load;
> +
> +			if (dld > busiest_load_per_task) {
> +				*imbalance = (dld + busiest_load_per_task) / 2;
> +				return busiest;
> +			}
> +		} else if (max_load - this_load >= busiest_load_per_task * 2) {
>  			*imbalance = busiest_load_per_task;
>  			return busiest;
>  		}

  reply	other threads:[~2006-04-11  1:13 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-10  6:45 [PATCH] sched: move enough load to balance average load per task Peter Williams
2006-04-11  1:12 ` Siddha, Suresh B [this message]
2006-04-11  1:57   ` Peter Williams
2006-04-11  5:47     ` Siddha, Suresh B
2006-04-11 23:46   ` Peter Williams
2006-04-12  1:57     ` Siddha, Suresh B
2006-04-12  5:06       ` Peter Williams
2006-04-12 16:55         ` Siddha, Suresh B
2006-04-12 23:13           ` Peter Williams
     [not found]         ` <443D95DF.2090807@bigpond.net.au>
2006-04-14  0:31           ` smpnice: issues with finding busiest queue Siddha, Suresh B
2006-04-14  1:17             ` Peter Williams

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=20060410181237.A26977@unix-os.sc.intel.com \
    --to=suresh.b.siddha@intel.com \
    --cc=akpm@osdl.org \
    --cc=efault@gmx.de \
    --cc=kenneth.w.chen@intel.com \
    --cc=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nickpiggin@yahoo.com.au \
    --cc=pwil3058@bigpond.net.au \
    /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