From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Paul Jackson <pj@sgi.com>
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu,
vatsa@linux.vnet.ibm.com, dhaval@linux.vnet.ibm.com,
nickpiggin@yahoo.com.au, ebiederm@xmission.com,
akpm@linux-foundation.org, sgrubb@redhat.com,
rostedt@goodmis.org, ghaskins@novell.com,
dmitry.adamushko@gmail.com, tong.n.li@intel.com,
tglx@linutronix.de, menage@google.com, rientjes@google.com
Subject: Re: scheduler scalability - cgroups, cpusets and load-balancing
Date: Tue, 29 Jan 2008 13:30:04 +0100 [thread overview]
Message-ID: <1201609804.28547.137.camel@lappy> (raw)
In-Reply-To: <20080129060355.7d38338f.pj@sgi.com>
On Tue, 2008-01-29 at 06:03 -0600, Paul Jackson wrote:
> Paul, responding to Peter:
> > > We now have a per-cpuset Boolean flag file called 'sched_load_balance'.
> >
> > SD_LOAD_BALANCE, right?
>
> No. SD_LOAD_BALANCE is some attribute of sched domains.
>
> The 'sched_load_balance' flag is an attribute of cpusets.
>
> The mapping of cpusets to sched domains required several pages of 'fun
> to write' code, which had to go through a couple of years of fixing and
> one major rewrite before it (knock on wood) worked correctly. It's not
> a one-to-one relation, in other words. See my earlier messages for
> further explanation of how this works.
Ok, I'll take a stab at understanding that code. Perhaps it seems to me
a lot of confusion could be solved by getting a more level playing
ground :-)
> > > This 'sched_load_balance' flag is, thus far, "the" cpuset hook
> > > supporting realtime. One can use it to configure a system so that
> > > the kernel does not do normal load balancing on select CPUs, such
> > > as those CPUs dedicated to realtime use.
> >
> > Ah, here I disagree, it is possible to do (hard) realtime scheduling
> > over multiple cpus, the only draw back is that it requires a very strong
> > load-balancer, making it unsuitable for large number of cpus.
>
> I don't think we are disagreeing. I was speaking of "normal"
> load balancing (what the mainline kernel/sched.c code normally
> does). You're speaking of hard realtime load balancing.
>
> I think we agree that these both exist, and require different
> load balancing code, the latter 'very strong.'
Great :-)
next prev parent reply other threads:[~2008-01-29 12:45 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-29 9:53 scheduler scalability - cgroups, cpusets and load-balancing Peter Zijlstra
2008-01-29 10:01 ` Paul Jackson
2008-01-29 10:50 ` Peter Zijlstra
2008-01-29 11:13 ` Paul Jackson
2008-01-29 11:31 ` Peter Zijlstra
2008-01-29 11:53 ` Paul Jackson
2008-01-29 12:07 ` Peter Zijlstra
2008-01-29 12:36 ` Paul Jackson
2008-01-29 12:03 ` Paul Jackson
2008-01-29 12:30 ` Peter Zijlstra [this message]
2008-01-29 12:52 ` Paul Jackson
2008-01-29 13:38 ` Peter Zijlstra
2008-01-29 10:57 ` Peter Zijlstra
2008-01-29 11:30 ` Paul Jackson
2008-01-29 11:34 ` Paul Jackson
2008-01-29 11:50 ` Peter Zijlstra
2008-01-29 12:12 ` Paul Jackson
2008-01-29 15:57 ` Gregory Haskins
2008-01-29 16:33 ` Paul Jackson
2008-01-29 15:50 ` Gregory Haskins
2008-01-29 16:51 ` Paul Jackson
2008-01-29 17:21 ` Gregory Haskins
2008-01-29 19:04 ` Paul Jackson
2008-01-29 20:36 ` Gregory Haskins
2008-01-29 21:02 ` Paul Jackson
2008-01-29 21:07 ` Gregory Haskins
2008-01-29 15:36 ` Gregory Haskins
2008-01-29 16:28 ` Paul Jackson
2008-01-29 16:42 ` Gregory Haskins
2008-01-29 19:37 ` Paul Jackson
2008-01-29 20:28 ` Gregory Haskins
2008-01-29 20:56 ` Paul Jackson
2008-01-29 21:02 ` Gregory Haskins
2008-01-29 22:23 ` Steven Rostedt
2008-01-29 12:32 ` Srivatsa Vaddagiri
2008-01-29 12:21 ` Paul Jackson
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=1201609804.28547.137.camel@lappy \
--to=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=dhaval@linux.vnet.ibm.com \
--cc=dmitry.adamushko@gmail.com \
--cc=ebiederm@xmission.com \
--cc=ghaskins@novell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=menage@google.com \
--cc=mingo@elte.hu \
--cc=nickpiggin@yahoo.com.au \
--cc=pj@sgi.com \
--cc=rientjes@google.com \
--cc=rostedt@goodmis.org \
--cc=sgrubb@redhat.com \
--cc=tglx@linutronix.de \
--cc=tong.n.li@intel.com \
--cc=vatsa@linux.vnet.ibm.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.