All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
To: "'Christoph Lameter'" <clameter@sgi.com>, "Ingo Molnar" <mingo@elte.hu>
Cc: "Siddha, Suresh B" <suresh.b.siddha@intel.com>, <akpm@osdl.org>,
	<mm-commits@vger.kernel.org>, <nickpiggin@yahoo.com.au>,
	<linux-kernel@vger.kernel.org>
Subject: RE: + sched-use-tasklet-to-call-balancing.patch added to -mm tree
Date: Tue, 7 Nov 2006 13:35:07 -0800	[thread overview]
Message-ID: <000001c702b4$9895c730$e734030a@amr.corp.intel.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0611071258280.5516@schroedinger.engr.sgi.com>

Christoph Lameter wrote on Tuesday, November 07, 2006 12:59 PM
> On Tue, 7 Nov 2006, Ingo Molnar wrote:
> 
> > Per-CPU tasklets are equivalent to softirqs, with extra complexity and 
> > overhead ontop of it :-)
> > 
> > so please just introduce a rebalance softirq and attach the scheduling 
> > rebalance tick to it. But i'd suggest to re-test on the 4096-CPU box, 
> > maybe what 'fixed' your workload was the global serialization of the 
> > tasklet. With a per-CPU softirq approach we are i think back to the same 
> > situation that broke your system before.
> 
> What broke the system was the disabling of interrupts over long time 
> periods during load balancing.


The previous global load balancing tasket could be an interesting data point.
Do you see a lot of imbalance in the system with the global tasket?  Does it
take prolonged interval to reach balanced system from imbalance?

Conceptually, it doesn't make a lot of sense to serialize load balance in the
System.  But in practice, maybe it is good enough to cycle through each cpu
(I suppose it all depends on the user environment).  This exercise certainly
make me to think in regards to what is the best algorithm in terms of efficiency
and minimal latency to achieve maximum system throughput.  Does kernel really
have to do load balancing so aggressively in polling mode? Perhaps an event
driven mechanism is a better solution.

- Ken


  reply	other threads:[~2006-11-07 21:35 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200611032205.kA3M5wmJ003178@shell0.pdx.osdl.net>
2006-11-07  7:32 ` + sched-use-tasklet-to-call-balancing.patch added to -mm tree Ingo Molnar
2006-11-07 17:44   ` Christoph Lameter
2006-11-07 17:31     ` Siddha, Suresh B
2006-11-07 17:55       ` Christoph Lameter
2006-11-07 17:50         ` Siddha, Suresh B
2006-11-07 18:18           ` Christoph Lameter
2006-11-07 19:17           ` Christoph Lameter
2006-11-07 20:31             ` Ingo Molnar
2006-11-07 20:59               ` Christoph Lameter
2006-11-07 21:35                 ` Chen, Kenneth W [this message]
2006-11-07 21:49                   ` Christoph Lameter
2006-11-10  6:18                     ` Chen, Kenneth W
2006-11-10 18:50                       ` Christoph Lameter
2006-11-10 21:38                         ` Ingo Molnar
2006-11-11  1:01                           ` Christoph Lameter
2006-11-11  2:05                             ` Chen, Kenneth W
2006-11-11  2:51                               ` Christoph Lameter
2006-11-13  4:03                                 ` Chen, Kenneth W
2006-11-13  5:44                                   ` Christoph Lameter
2006-11-13  6:40                                     ` Chen, Kenneth W
2006-11-14  1:06                                       ` [patch] sched domain: move sched group allocations to percpu area Siddha, Suresh B
2006-11-14  8:23                                         ` Ingo Molnar
2006-11-14 16:57                                         ` Christoph Lameter
2006-11-10 21:42                         ` + sched-use-tasklet-to-call-balancing.patch added to -mm tree Ingo Molnar
2006-11-10 22:32                         ` Siddha, Suresh B
2006-11-11  1:14                           ` Christoph Lameter
2006-11-07 19:22           ` Christoph Lameter
2006-11-07 20:29         ` Ingo Molnar

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='000001c702b4$9895c730$e734030a@amr.corp.intel.com' \
    --to=kenneth.w.chen@intel.com \
    --cc=akpm@osdl.org \
    --cc=clameter@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mm-commits@vger.kernel.org \
    --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.