From: Erich Focht <efocht@hpce.nec.com>
To: habanero@us.ibm.com, "Martin J. Bligh" <mbligh@aracnet.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
LSE <lse-tech@lists.sourceforge.net>
Cc: Andi Kleen <ak@muc.de>, torvalds@osdl.org
Subject: Re: [Lse-tech] Re: [patch] scheduler fix for 1cpu/node case
Date: Wed, 30 Jul 2003 17:23:55 +0200 [thread overview]
Message-ID: <200307301723.55148.efocht@hpce.nec.com> (raw)
In-Reply-To: <200307290833.05216.habanero@us.ibm.com>
On Tuesday 29 July 2003 15:33, Andrew Theurer wrote:
> > The fact that global rebalances are done only in the timer interrupt
> > is simply bad!
>
> Even with this patch it still seems that most balances are still timer
> based, because we still call load_balance in rebalance_tick. Granted, we
> may inter-node balance more often, well, maybe less often since
> node_busy_rebalance_tick was busy_rebalance_tick*2. I do see the advantage
> of doing this at idle, but idle only, that's why I'd would be more inclined
> a only a much more aggressive idle rebalance.
Without this patch the probability to globally balance when going idle
is 0. Now it is 1/global_balance_rate(cpus_in_this_node) . This is
tunable and we can make this probability depending on the node load
imbalance. I'll try that in the next version, it sounds like a good
idea. Also changing this probability by some factor could give us a
way to handle the differences between the platforms.
Balancing globally only when idle isn't a good idea as long as we
don't have multiple steals per balance attempt. Even then, tasks don't
live all the same time, so you easilly end up with one node overloaded
and others just busy and not able to steal from the busiest node.
> > It complicates rebalance_tick() and wastes the
> > opportunity to get feedback from the failed local balance attempts.
>
> What does "failed" really mean? To me, when *busiest=null, that means we
> passed, the node itself is probably balanced, and there's nothing to do.
> It gives no indication at all of the global load [im]balance. Shouldn't
> the thing we are looking for is the imbalance among node_nr_running[]?
> Would it make sense to go forward with a global balance based on that only?
I'll try to include the node imbalance in the global balance rate
calculation, let's see how it works. Just wanted to fix one issue with
my patch, now it looks like it provides some simple ways to solve
other issues as well... Thanks for the idea!
Regards,
Erich
next prev parent reply other threads:[~2003-07-30 15:23 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-28 19:16 [patch] scheduler fix for 1cpu/node case Erich Focht
2003-07-28 19:55 ` Martin J. Bligh
2003-07-28 20:18 ` Erich Focht
2003-07-28 20:37 ` Martin J. Bligh
2003-07-29 2:24 ` Andrew Theurer
2003-07-29 10:08 ` Erich Focht
2003-07-29 13:33 ` [Lse-tech] " Andrew Theurer
2003-07-30 15:23 ` Erich Focht [this message]
2003-07-30 15:44 ` Andrew Theurer
2003-07-29 14:27 ` Martin J. Bligh
2003-08-13 20:49 ` Bill Davidsen
2003-08-22 15:46 ` [Lse-tech] " Andrew Theurer
2003-08-22 22:56 ` Nick Piggin
2003-08-23 0:12 ` Andrew Theurer
2003-08-23 0:29 ` Nick Piggin
2003-08-23 0:47 ` William Lee Irwin III
2003-08-23 8:48 ` Nick Piggin
2003-08-23 14:32 ` Andrew Theurer
2003-08-23 1:31 ` Martin J. Bligh
2003-07-29 10:08 ` Erich Focht
2003-07-29 14:41 ` Andi Kleen
2003-07-31 15:05 ` Martin J. Bligh
2003-07-31 21:45 ` Erich Focht
2003-08-01 0:26 ` Martin J. Bligh
2003-08-01 16:30 ` [Lse-tech] " Erich Focht
-- strict thread matches above, loose matches on Subject: below --
2003-07-29 14:06 Mala Anand
2003-07-29 14:29 ` Martin J. Bligh
2003-07-29 16:04 Mala Anand
2003-07-30 16:34 Luck, Tony
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=200307301723.55148.efocht@hpce.nec.com \
--to=efocht@hpce.nec.com \
--cc=ak@muc.de \
--cc=habanero@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lse-tech@lists.sourceforge.net \
--cc=mbligh@aracnet.com \
--cc=torvalds@osdl.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox