On Tue, Apr 17, 2007 at 04:03:41PM +1000, Peter Williams wrote: > Nick Piggin wrote: > > > >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
I agree that some of that has exploded complexity. I have some thoughts about better approaches for some of those things, but basically been stuck working on VM problems for a while. > 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. Put it this way: it is trivial to group the load balancing stats of N CPUs with their own runqueues. Just put them under a domain and take the sum. The domain essentially takes on the same function as a single queue with N CPUs under it. Anything _further_ you can do with individual runqueues (like naturally adding an affinity pressure ranging from nothing to absolute) are things that you don't trivially get with 1:N approach. AFAIKS. So I will definitely give any idea consideration, but I just need to be shown where the benefit comes from. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
