mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
Cc: Ingo Molnar <mingo@elte.hu>, Andrew Morton <akpm@osdl.org>,
	lkml <linux-kernel@vger.kernel.org>,
	steiner@sgi.com, dvhltc@us.ibm.com, mbligh@mbligh.org
Subject: Re: allow the load to grow upto its cpu_power (was Re: [Patch] don't kick ALB in the presence of pinned task)
Date: Thu, 11 Aug 2005 13:09:10 +1000	[thread overview]
Message-ID: <1123729750.5188.13.camel@npiggin-nld.site> (raw)
In-Reply-To: <20050809190352.D1938@unix-os.sc.intel.com>

[-- Attachment #1: Type: text/plain, Size: 1569 bytes --]

On Tue, 2005-08-09 at 19:03 -0700, Siddha, Suresh B wrote:
> On Wed, Aug 10, 2005 at 10:27:44AM +1000, Nick Piggin wrote:
> > Yeah this makes sense. Thanks.
> > 
> > I think we'll only need your first line change to fix this, though.
> > 
> > Your second change will break situations where a single group is very
> > loaded, but it is in a domain with lots of cpu_power
> > (total_load <= total_power).
> 
> In that case, we will move the excess load from that group to some
> other group which is below its capacity. Instead of bringing everyone
> to avg load, we make sure that everyone is at or below its cpu_power.
> This will minimize the movements between the nodes.
> 
> For example, Let us assume sched groups node-0, node-1 each has 
> 4*SCHED_LOAD_SCALE as its cpu_power.
> 
> And with 6 tasks on node-0 and 0 on node-1, current load balance 
> will move 3 tasks from node-0 to 1. But with my patch, it will move only 
> 2 tasks to node-1. Is this what you are referring to as breakage?
> 

No, I had thought it was possible to get into a situation where
one queue could be very loaded but not have anyone to pull from
it if total_load <= total_pwr.

I see that shouldn't happen though.

I have a variation on the 2nd part of your patch which I think
I would prefer. IMO it kind of generalises the current imbalance
calculation to handle this case rather than introducing a new
special case.

Untested as yet, but I'll queue it to send to Andrew after it
gets some testing - unless you have any objections that is.

Thanks,
Nick

-- 
SUSE Labs, Novell Inc.



[-- Attachment #2: sched-fix-fbg.patch --]
[-- Type: text/x-patch, Size: 1578 bytes --]

Don't pull tasks from a group if that would cause the
group's total load to drop below its total cpu_power
(ie. cause the group to start going idle).

Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Nick Piggin <npiggin@suse.de>

Index: linux-2.6/kernel/sched.c
===================================================================
--- linux-2.6.orig/kernel/sched.c	2005-08-11 12:10:10.199651212 +1000
+++ linux-2.6/kernel/sched.c	2005-08-11 12:53:15.361971195 +1000
@@ -1886,6 +1886,7 @@
 {
 	struct sched_group *busiest = NULL, *this = NULL, *group = sd->groups;
 	unsigned long max_load, avg_load, total_load, this_load, total_pwr;
+	unsigned long max_pull;
 	int load_idx;
 
 	max_load = this_load = total_load = total_pwr = 0;
@@ -1932,7 +1933,7 @@
 		group = group->next;
 	} while (group != sd->groups);
 
-	if (!busiest || this_load >= max_load)
+	if (!busiest || this_load >= max_load || max_load <= SCHED_LOAD_SCALE)
 		goto out_balanced;
 
 	avg_load = (SCHED_LOAD_SCALE * total_load) / total_pwr;
@@ -1952,8 +1953,12 @@
 	 * by pulling tasks to us.  Be careful of negative numbers as they'll
 	 * appear as very large values with unsigned longs.
 	 */
+
+	/* Don't want to pull so many tasks that a group would go idle */
+	max_pull = min(max_load - avg_load, max_load - SCHED_LOAD_SCALE);
+	
 	/* How much load to actually move to equalise the imbalance */
-	*imbalance = min((max_load - avg_load) * busiest->cpu_power,
+	*imbalance = min(max_pull * busiest->cpu_power,
 				(avg_load - this_load) * this->cpu_power)
 			/ SCHED_LOAD_SCALE;
 

  reply	other threads:[~2005-08-11  3:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-02  0:42 [Patch] don't kick ALB in the presence of pinned task Siddha, Suresh B
2005-08-02  6:09 ` Nick Piggin
2005-08-02  9:43   ` Ingo Molnar
2005-08-02 10:06     ` Nick Piggin
2005-08-02 21:12   ` Siddha, Suresh B
2005-08-02  9:27 ` Ingo Molnar
2005-08-09 23:08   ` allow the load to grow upto its cpu_power (was Re: [Patch] don't kick ALB in the presence of pinned task) Siddha, Suresh B
2005-08-10  0:27     ` Nick Piggin
2005-08-10  2:03       ` Siddha, Suresh B
2005-08-11  3:09         ` Nick Piggin [this message]
2005-08-11 18:14           ` Siddha, Suresh B
2005-08-11 23:49             ` Nick Piggin
2005-08-12  0:39               ` Siddha, Suresh B
2005-08-12  1:24                 ` Nick Piggin
2005-08-12  1:44                   ` Siddha, Suresh B
2005-08-10  7:16     ` Ingo Molnar

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=1123729750.5188.13.camel@npiggin-nld.site \
    --to=nickpiggin@yahoo.com.au \
    --cc=akpm@osdl.org \
    --cc=dvhltc@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@mbligh.org \
    --cc=mingo@elte.hu \
    --cc=steiner@sgi.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®