Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]

Nick Piggin
2007-04-17T06:23:17Z

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.