All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Williams <pwil3058@bigpond.net.au>
To: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
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>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] sched: move enough load to balance average load per task
Date: Wed, 12 Apr 2006 09:46:32 +1000	[thread overview]
Message-ID: <443C3FD8.2060906@bigpond.net.au> (raw)
In-Reply-To: <20060410181237.A26977@unix-os.sc.intel.com>

Siddha, Suresh B wrote:
> 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...)

Well, first off, we don't always move busiest_load_per_task we move UP 
TO busiest_load_per_task so there is no way you can make definitive 
statements about what will happen to the value "this_load_per_task" as a 
result of setting *imbalance to busiest_load_per_task.  Load balancing 
is a probabilistic endeavour and we need to take steps that increase the 
probability that we get the desired result.

Without this patch there is no chance that busiest_load_per_task will 
get smaller and whether this_load_per_task will get bigger is 
indeterminate.  With this patch there IS a chance that 
busiest_load_per_task will decrease and an INCREASED chance that 
this_load_per_task will get bigger.  Ergo we have increased the 
probability that the (absolute) difference between this_load_per_task 
and busiest_load_per_task will decrease.  This is a desirable outcome.

Peter
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce

  parent reply	other threads:[~2006-04-11 23:46 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
2006-04-11  1:57   ` Peter Williams
2006-04-11  5:47     ` Siddha, Suresh B
2006-04-11 23:46   ` Peter Williams [this message]
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=443C3FD8.2060906@bigpond.net.au \
    --to=pwil3058@bigpond.net.au \
    --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=suresh.b.siddha@intel.com \
    /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.