From: Ingo Molnar <mingo@elte.hu>
To: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
Cc: nickpiggin@yahoo.com.au, akpm@osdl.org,
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: Wed, 10 Aug 2005 09:16:08 +0200 [thread overview]
Message-ID: <20050810071608.GC21052@elte.hu> (raw)
In-Reply-To: <20050809160813.B1938@unix-os.sc.intel.com>
* Siddha, Suresh B <suresh.b.siddha@intel.com> wrote:
> On Tue, Aug 02, 2005 at 11:27:17AM +0200, Ingo Molnar wrote:
> >
> > * Siddha, Suresh B <suresh.b.siddha@intel.com> wrote:
> >
> > > Jack Steiner brought this issue at my OLS talk.
> > >
> > > Take a scenario where two tasks are pinned to two HT threads in a physical
> > > package. Idle packages in the system will keep kicking migration_thread
> > > on the busy package with out any success.
> > >
> > > We will run into similar scenarios in the presence of CMP/NUMA.
> > >
> > > Patch appended.
> > >
> > > Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
> >
> > nice catch!
> >
> > fine for -mm, but i dont think we need this fix in 2.6.13, as the effect
> > of the bug is an extra context-switch per 'CPU goes idle' event, in this
> > very specific (and arguably broken) task binding scenario.
>
> No. This is not a broken scenario. Its possible in NUMA case aswell.
>
> For example, lets take two nodes each having two physical packages.
> And assume that there are two tasks and both of them are on (may or
> may n't be pinned) two packages in node-0
>
> Todays load balance will detect that there is an imbalance between the
> two nodes and will try to distribute the load between the nodes.
>
> In general, we should allow the load of a group to grow upto its
> cpu_power and stop preventing these costly movements.
>
> Appended patch will fix this. I have done limited testing of this
> patch. Guys with big NUMA boxes, please give this patch a try.
makes sense in general - we should not try to move things around when we
are under-utilized. (In theory there could be heavily fluctuating
workloads which do not produce an above 100% average utilization, and
which could benefit from a perfectly even distribution of tasks - but i
dont think the load-balancer should care, as load-balancing is mostly a
"slow" mechanism.)
Again, 2.6.14 stuff.
Acked-by: Ingo Molnar <mingo@elte.hu>
Ingo
prev parent reply other threads:[~2005-08-10 7:16 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
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 [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=20050810071608.GC21052@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@osdl.org \
--cc=dvhltc@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@mbligh.org \
--cc=nickpiggin@yahoo.com.au \
--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 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.