![]() | |||||||||||||
Messages in this thread |
Nick Piggin wrote: > On Tue, Apr 17, 2007 at 02:25:39PM +1000, Peter Williams wrote: >> Nick Piggin wrote: >>> On Mon, Apr 16, 2007 at 04:10:59PM -0700, Michael K. Edwards wrote: >>>> On 4/16/07, Peter Williams <pwil3058@bigpond.net.au> wrote: >>>>> Note that I talk of run queues >>>>> not CPUs as I think a shift to multiple CPUs per run queue may be a good >>>>> idea. >>>> This observation of Peter's is the best thing to come out of this >>>> whole foofaraw. Looking at what's happening in CPU-land, I think it's >>>> going to be necessary, within a couple of years, to replace the whole >>>> idea of "CPU scheduling" with "run queue scheduling" across a complex, >>>> possibly dynamic mix of CPU-ish resources. Ergo, there's not much >>>> point in churning the mainline scheduler through a design that isn't >>>> significantly more flexible than any of those now under discussion. >>> Why? If you do that, then your load balancer just becomes less flexible >>> because it is harder to have tasks run on one or the other. >>> >>> You can have single-runqueue-per-domain behaviour (or close to) just by >>> relaxing all restrictions on idle load balancing within that domain. It >>> is harder to go the other way and place any per-cpu affinity or >>> restirctions with multiple cpus on a single runqueue. >> Allowing N (where N can be one or greater) CPUs per run queue actually >> increases flexibility as you can still set N to 1 to get the current >> behaviour. > > But you add extra code for that on top of what we have, and are also > prevented from making per-cpu assumptions. > > And you can get N CPUs per runqueue behaviour by having them in a domain > with no restrictions on idle balancing. So where does your increased > flexibilty come from? > >> One advantage of allowing multiple CPUs per run queue would be at the >> smaller end of the system scale i.e. a PC with a single hyper threading >> chip (i.e. 2 CPUs) would not need to worry about load balancing at all >> if both CPUs used the one runqueue and all the nasty side effects that >> come with hyper threading would be minimized at the same time. > > I don't know about that -- the current load balancer already minimises > the nasty multi threading effects. SMT is very important for IBM's chips > for example, and they've never had any problem with that side of it > since it was introduced and bugs ironed out (at least, none that I've > heard). > There's a lot of ugly code in the load balancer that is only there to overcome the side effects of SMT and dual core. A lot of it was put there by Intel employees trying to make load balancing more friendly to their systems. What I'm suggesting is that an N CPUs per runqueue is a better way of achieving that end. I may (of course) be wrong but I think that the idea deserves more consideration than you're willing to give it. Peter -- Peter Williams pwil3058@bigpond.net.au "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2007-04-17 08:07 [from the cache] ©2003-2008 | |||||||||||||