All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <piggin@cyberone.com.au>
To: Rick Lindsley <ricklind@us.ibm.com>
Cc: "Martin J. Bligh" <mbligh@aracnet.com>,
	Anton Blanchard <anton@samba.org>,
	akpm@osdl.org, linux-kernel@vger.kernel.org, dvhltc@us.ibm.com
Subject: Re: [PATCH] Load balancing problem in 2.6.2-mm1
Date: Sat, 07 Feb 2004 10:20:50 +1100	[thread overview]
Message-ID: <40242152.5030606@cyberone.com.au> (raw)
In-Reply-To: <200402062311.i16NBdF14365@owlet.beaverton.ibm.com>



Rick Lindsley wrote:

>    OK, but do you agree that the rate we rebalance things like 2 vs 1 should
>    be slower than the rate we rebalance 3 vs 1 ? Fairness is only relevant
>    over a long term imbalance anyway, so there should be a big damper on
>    "fairness only" rebalances.
>
>I think, given the precision we're granted via SCHED_LOAD_SCALE, in
>combination with the new "load average" (cpu_load) code, that we can
>achieve what we want.
>
>If cpu0 has 2 runnable tasks and cpu1 has 1 runnable task, won't we see
>the "load average" of cpu0 slowly approach 2, but not jump there?
>
>

Yep

>Right now, we round up on all fractions and Martin has proposed a patch
>which takes it the other way and rounds down.  What if in marginal
>cases like this where this is a small but persistent difference, we
>could bump the task to another cpu when it reaches (say) 1.8 or 1.9?
>That would keep it there longer for shorter-lived tasks, but for those
>long-runners, they'd eventually spread the pain around a little.
>
>And yes, a cpu_load of even 1.0 should *never* get migrated to a cpu
>with a load 0.0.  Instead of
>

This isn't the load though, but imbalance. It has already passed
through our imbalance_pct filter (or we are idle), so we can pretty
safely assume that we want to try to move at least one task.

>
>    *imbalance = (*imbalance + SCHED_LOAD_SCALE - 1) >> SCHED_LOAD_SHIFT;
>
>how about, for instance,
>
>    if (max_load <= SCHED_LOAD_SCALE)
>	*imbalance = 0;
>    else
>	*imbalance = (*imbalance + (SCHED_LOAD_SCALE / 6) - 1)
>	    >> SCHED_LOAD_SHIFT;
>
>The intent is to never move anything if max_load is 1 or less (what
>advantage is there?) and to create a slight tendency to round up at
>loads greater than that, which would still tend to leave things where
>they were until they'd been there a while.  In fact the "bonus"
>(SCHED_LOAD_SCALE / 6 - 1) could be another configurable in the scheduling
>domain so that at some level you're not interested in fairness and
>they just don't bounce at all.
>
>

Hopefully just tending to round down more would damp it better.
*imbalance = (*imbalance + SCHED_LOAD_SCALE/2) >> SCHED_LOAD_SHIFT;
Or even remove the addition all together.


  reply	other threads:[~2004-02-06 23:23 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-06  9:24 [PATCH] Load balancing problem in 2.6.2-mm1 Rick Lindsley
2004-02-06  9:38 ` Nick Piggin
2004-02-06 18:13   ` Rick Lindsley
2004-02-06 21:57     ` Nick Piggin
2004-02-06 22:30       ` Rick Lindsley
2004-02-06 22:40         ` Nick Piggin
2004-02-06 22:49           ` Rick Lindsley
2004-02-06 23:08             ` Nick Piggin
2004-02-06 10:30 ` Anton Blanchard
2004-02-06 18:15   ` Rick Lindsley
2004-02-06 18:39     ` Martin J. Bligh
2004-02-06 22:02       ` Nick Piggin
2004-02-06 22:34         ` Rick Lindsley
2004-02-06 22:48           ` Nick Piggin
2004-02-06 22:42         ` Martin J. Bligh
2004-02-06 22:53           ` Nick Piggin
2004-02-06 23:11           ` Rick Lindsley
2004-02-06 23:20             ` Nick Piggin [this message]
2004-02-06 23:33               ` Martin J. Bligh
2004-02-06 23:41                 ` Nick Piggin
2004-02-06 23:47                   ` Martin J. Bligh
2004-02-07  0:11                     ` Nick Piggin
2004-02-07  0:25                       ` Martin J. Bligh
2004-02-07  0:31                         ` Nick Piggin
2004-02-07  9:50                           ` Anton Blanchard
2004-02-08  0:40                             ` Rick Lindsley
2004-02-08  1:12                               ` Anton Blanchard
2004-02-08  1:21                                 ` Nick Piggin
2004-02-08  1:41                                   ` Anton Blanchard
2004-02-08  3:20                                     ` Nick Piggin
2004-02-08  3:57                                       ` Anton Blanchard
2004-02-08  4:05                                         ` Nick Piggin
2004-02-08 12:14                                           ` Anton Blanchard
2004-02-08  1:22                                 ` Anton Blanchard
2004-02-09 16:37                       ` Timothy Miller
2004-02-09 16:43                         ` Martin J. Bligh
2004-02-06 18:33   ` Martin J. Bligh

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=40242152.5030606@cyberone.com.au \
    --to=piggin@cyberone.com.au \
    --cc=akpm@osdl.org \
    --cc=anton@samba.org \
    --cc=dvhltc@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@aracnet.com \
    --cc=ricklind@us.ibm.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.