[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200709300521.03356.nickpiggin@yahoo.com.au>
Date: Sun, 30 Sep 2007 05:21:02 +1000
From: Nick Piggin <nickpiggin@...oo.com.au>
To: Paul Jackson <pj@....com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Paul Menage <menage@...gle.com>, linux-kernel@...r.kernel.org,
Dinakar Guniguntala <dino@...ibm.com>, cpw@....com,
Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] cpuset and sched domains: sched_load_balance flag
On Sunday 30 September 2007 20:44, Paul Jackson wrote:
> From: Paul Jackson <pj@....com>
>
> Add a new per-cpuset flag called 'sched_load_balance'.
>
> When enabled in a cpuset (the default value) it tells the kernel
> scheduler that the scheduler should provide the normal load
> balancing on the CPUs in that cpuset, sometimes moving tasks
> from one CPU to a second CPU if the second CPU is less loaded
> and if that task is allowed to run there.
I don't like adding these funny special case sort of things like this.
The user should just be able to specify exactly the partitioning of
tasks required, and cpusets should ask the scheduler to do the best
job of load balancing possible.
I implemented that with my patches to do automatic discovery
of the largest set of disjoint cpusets.
>From there, the problem that cpusets has, is that it lacks a good
way to specify that the machine should be partitioned (IIRC because
stuff defaults to going into the root cpuset which covers all CPUs?).
Instead of adding these "I want the scheduler to do something a bit
vague but hopefully good albeit with some downsides" flags, there
should be a way to say "I want to partition the CPUs like so...", IMO.
Barring that (ie. maybe you always want a root cpuset to cover all
CPUs), then maybe we should retain the spanning sched domains
in order to balance the root cpuset, and add another set of domains
according to cpuset partitioning. This could be entirely transparent
to userspace, I think (using my patch).
Just my opinion. Good to see more thought going into this area, because
it is something that sched-domains can do really well but is underused.
-
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