[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4537527B.5050401@yahoo.com.au>
Date: Thu, 19 Oct 2006 20:24:59 +1000
From: Nick Piggin <nickpiggin@...oo.com.au>
To: Paul Jackson <pj@....com>
CC: Andrew Morton <akpm@...l.org>, Martin Bligh <mbligh@...gle.com>,
Paul Menage <menage@...gle.com>, Simon.Derr@...l.net,
linux-kernel@...r.kernel.org,
Dinakar Guniguntala <dino@...ibm.com>,
Rohit Seth <rohitseth@...gle.com>, Robin Holt <holt@....com>,
dipankar@...ibm.com, "Siddha, Suresh B" <suresh.b.siddha@...el.com>
Subject: Re: [RFC] cpuset: remove sched domain hooks from cpusets
Paul Jackson wrote:
> From: Paul Jackson <pj@....com>
>
> Remove the cpuset hooks that defined sched domains depending on the
> setting of the 'cpu_exclusive' flag.
Before we chuck the baby out...
> The cpu_exclusive flag can only be set on a child if it is set on
> the parent.
>
> This made that flag painfully unsuitable for use as a flag defining
> a partitioning of a system.
Sigh, it isn't. That's simply how cpusets tried to use it.
> It was entirely unobvious to a cpuset user what partitioning of sched
> domains they would be causing when they set that one cpu_exclusive bit
> on one cpuset, because it depended on what CPUs were in the remainder
> of that cpusets siblings and child cpusets, after subtracting out
> other cpu_exclusive cpusets.
As far as a user is concerned, the cpusets is the interface. domain
partitioning is an implementation detail that just happens to make
it work better in some cases.
> Furthermore, there was no way on production systems to query the
> result.
You shouldn't need to, assuming cpusets doesn't mess it up.
Here is an untested patch. Apparently takes care of CPU hotplug too.
--
SUSE Labs, Novell Inc.
View attachment "sched-domains-cpusets-fixes.patch" of type "text/plain" (8468 bytes)
Powered by blists - more mailing lists