From: Nick Piggin <piggin@cyberone.com.au>
To: Andrew Theurer <habanero@us.ibm.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Nick's scheduler v17
Date: Tue, 28 Oct 2003 10:13:19 +1100 [thread overview]
Message-ID: <3F9DA68F.5080000@cyberone.com.au> (raw)
In-Reply-To: <200310271102.59041.habanero@us.ibm.com>
Andrew Theurer wrote:
>>>> *imbalance = min(this_load - load_avg, load_avg - max_load)
>>>>
>>>>That way you take just enough to either have busiest_queue or
>>>>this_rq's length be the load_avg. I suppose you could take even
>>>>less, but IMO, the /=2 is what I really don't like. Perhaps:
>>>>
>>>That is _exactly_ what I had before! Thats probably the way to go. Thanks
>>>for having a look at it.
>>>
>>>
>>>>*imbalance = min(this_load - load_avg, load_avg - max_load);
>>>>*imbalance = (*imbalance + FPT - 1) / FPT;
>>>>
>>>>This should work well for intranode balances, internode balances may
>>>>need a little optimization, since the load_avg really does not really
>>>>represent the load avg of the two nodes in question, just one cpu
>>>>from one of them and all the cpus from another.
>>>>
>>Oh, actually, after my path, load_avg represents the load average of _all_
>>the nodes. Have a look at find_busiest_node. Which jogs my memory of why
>>its not always a good idea to do your *imbalance min(...) thing (I actually
>>saw this happening).
>>
>
>Oops, I meant avg_load, which you calculate in find_busiest_queue on the fly.
>
OK
>
>>5 CPUs, 4 processes running on one cpu. load_avg would be 0.8 for all cpus.
>>balancing doesn't happen. I have to think about this a bit more...
>>
>
>Actually, if we use avg_load, I guess it would be 0, since this is an unsigned
>long. Maybe avg_load needs to have a min value of 1. Then if we apply:
>
Well its got a fixed point scaling factor.
>
>*imbalance = min(max_load - avg_load, avg_load - this_load)
> min(4 - 1, 1 - 0)
>
>
I think you want:
*imbalance = min(max_load - avg_load, avg_load - this_load)
if ( (*imbalance < 1*FPT) &&
(max_load - this_load) > 1*FPT )
*imbalance = 1*FPT;
So if there is a total imbalance of more than 1 task, at least one
will be moved.
>
>And imbalance looks a lot better. Only concern would be an idle cpu stealing
>from another, leaving the other cpu idle. I guess a check could be put
>there.
>
>
pull_task won't pull a running task, so you get some protection there.
prev parent reply other threads:[~2003-10-27 23:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-24 18:10 Nick's scheduler v17 Nick Piggin
2003-10-24 20:17 ` cliff white
2003-10-24 21:49 ` Andrew Theurer
2003-10-25 1:12 ` Nick Piggin
2003-10-26 6:43 ` Nick Piggin
2003-10-27 17:02 ` Andrew Theurer
2003-10-27 23:13 ` Nick Piggin [this message]
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=3F9DA68F.5080000@cyberone.com.au \
--to=piggin@cyberone.com.au \
--cc=habanero@us.ibm.com \
--cc=linux-kernel@vger.kernel.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.