From: Peter Williams <pwil3058@bigpond.net.au>
To: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
Cc: Andrew Morton <akpm@osdl.org>, Mike Galbraith <efault@gmx.de>,
Nick Piggin <nickpiggin@yahoo.com.au>,
Ingo Molnar <mingo@elte.hu>, Con Kolivas <kernel@kolivas.org>,
"Chen, Kenneth W" <kenneth.w.chen@intel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] sched: smpnice work around for active_load_balance()
Date: Wed, 29 Mar 2006 13:14:42 +1100 [thread overview]
Message-ID: <4429ED92.9040602@bigpond.net.au> (raw)
In-Reply-To: <4429BC61.7020201@bigpond.net.au>
Peter Williams wrote:
> Siddha, Suresh B wrote:
>> On Tue, Mar 28, 2006 at 05:00:50PM +1100, Peter Williams wrote:
[bits deleted]
>>
>> Even with no HT and MC, this patch has still has issues in the presence
>> of different priority tasks... consider a simple DP system and run two
>> instances of high priority tasks(simple infinite loop) and two normal
>> priority
>> tasks. With "top" I observed that these normal priority tasks keep on
>> jumping
>> from one processor to another... Ideally with smpnice, we would assume
>> that each processor should have two tasks (one high priority and
>> another one with normal priority) ..
>
> Yes, but you are failing to take into account the effect of the other
> tasks on your system (e.g. top) that run from time to time. If their
> burst of CPU use happens to coincide with some load balancing activity
> they will cause an imbalance to be detected (that is different to that
> which only considers your test tasks) and this will result in some tasks
> being moved. Beware the Heisenberg Uncertainty Principle :-).
Notwithstanding the HUP, I've investigated this and have found that
there is more instability than expected and that it is due to a silly
bit of code (by me) at the end of find_busiest_queue() marked by the
comment:
/* or if there's a reasonable chance that *imbalance is big
* enough to cause a move
*/
that makes load balancing more aggressive. The functionality it
implemented should have been abandoned when the code was updated to use
average run queue loads instead of SCHED_LOAD_SCALE in the code that
handled small imbalances but wasn't. I'll send Andrew a patch that
removes the offending code shortly.
Peter
--
Peter Williams pwil3058@bigpond.net.au
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
next prev parent reply other threads:[~2006-03-29 2:14 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-28 6:00 [PATCH] sched: smpnice work around for active_load_balance() Peter Williams
2006-03-28 19:25 ` Siddha, Suresh B
2006-03-28 22:44 ` Peter Williams
2006-03-29 2:14 ` Peter Williams [this message]
2006-03-29 2:52 ` Siddha, Suresh B
2006-03-29 3:42 ` Peter Williams
2006-03-29 22:52 ` Siddha, Suresh B
2006-03-29 23:40 ` Peter Williams
2006-03-30 0:50 ` Siddha, Suresh B
2006-03-30 1:14 ` Peter Williams
2006-04-02 4:48 ` smpnice loadbalancing with high priority tasks Siddha, Suresh B
2006-04-02 7:08 ` Peter Williams
2006-04-04 0:24 ` Siddha, Suresh B
2006-04-04 1:22 ` Peter Williams
2006-04-04 1:34 ` Peter Williams
2006-04-04 2:11 ` Siddha, Suresh B
2006-04-04 3:24 ` Peter Williams
2006-04-04 4:34 ` Peter Williams
2006-04-06 2:14 ` Peter Williams
2006-04-20 1:24 ` [patch] smpnice: don't consider sched groups which are lightly loaded for balancing Siddha, Suresh B
2006-04-20 5:19 ` Peter Williams
2006-04-20 16:54 ` Siddha, Suresh B
2006-04-20 23:11 ` Peter Williams
2006-04-20 23:49 ` Andrew Morton
2006-04-21 0:25 ` Siddha, Suresh B
2006-04-21 0:28 ` Peter Williams
2006-04-21 1:25 ` Andrew Morton
2006-04-20 17:04 ` Siddha, Suresh B
2006-04-21 0:00 ` Peter Williams
2006-04-03 1:04 ` [PATCH] sched: smpnice work around for active_load_balance() Peter Williams
2006-04-03 16:57 ` Siddha, Suresh B
2006-04-03 23:11 ` 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=4429ED92.9040602@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.