[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080129150234.b57ce988.pj@sgi.com>
Date: Tue, 29 Jan 2008 15:02:34 -0600
From: Paul Jackson <pj@....com>
To: "Gregory Haskins" <ghaskins@...ell.com>
Cc: a.p.zijlstra@...llo.nl, mingo@...e.hu, dmitry.adamushko@...il.com,
rostedt@...dmis.org, menage@...gle.com, rientjes@...gle.com,
tong.n.li@...el.com, tglx@...utronix.de, akpm@...ux-foundation.org,
dhaval@...ux.vnet.ibm.com, vatsa@...ux.vnet.ibm.com,
sgrubb@...hat.com, linux-kernel@...r.kernel.org,
ebiederm@...ssion.com, nickpiggin@...oo.com.au
Subject: Re: scheduler scalability - cgroups, cpusets and load-balancing
Gregory wrote:
> > ... (1) turning off
> > sched_load_balance in any overlapping cpusets, including all
> > encompassing parent cpusets, (2) leaving sched_load_balance on in the
> > RT cpuset itself, and ...
>
> Technically you only need (2). I run my 4-8 core development systems
> in the single default global cpuset, normally.
Well, if you're running in the default cpuset, then you automatically get (1),
because sched_load_balance is turned off in all overlapping cpusets (there
aren't any overlapping cpusets!)
So, yes, you -do- need both (1) and (2). In your normal system, you
just happen to get (1) effortlessly.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@....com> 1.940.382.4214
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists