Re: Nick's scheduler v17

[Nick Piggin]

Nick Piggin wrote:

> Andrew Theurer wrote:
>
> > On Friday 24 October 2003 13:10, Nick Piggin wrote:
> >
> > > Hi,
> > > http://www.kerneltrap.org/~npiggin/v17/
> > >
> > > Still working on SMP and NUMA. Some (maybe) interesting things I put 
> > > in are
> > > - Sequential CPU balancing so you don't get a big storm of balances
> > > every 1/4s.
> > > - Balancing is trying to err more on the side of caution, I have to 
> > > start
> > >  analysing it more thoroughly though.
> >
> > +
> > +    *imbalance /= 2;
> > +    *imbalance = (*imbalance + FPT - 1) / FPT;
> >
> > I think I see what is going on here, but would something like this 
> > work out better?
>
> Yeah, sorry its not well commented. Its still changing quite quickly.
>
> >     *imbalance = min(this_load - load_avg, load_avg - max_load)
> >
> > That way you take just enough to either have busiest_queue or 
> > this_rq's length be the load_avg.  I suppose you could take even 
> > less, but IMO, the /=2 is what I really don't like.  Perhaps:
>
> That is _exactly_ what I had before! Thats probably the way to go. Thanks
> for having a look at it.
>
> > *imbalance = min(this_load - load_avg, load_avg - max_load);
> > *imbalance = (*imbalance + FPT - 1) / FPT;
> >
> > This should work well for intranode balances, internode balances may 
> > need a little optimization, since the load_avg really does not really 
> > represent the load avg of the two nodes in question, just one cpu 
> > from one of them and all the cpus from another.

Oh, actually, after my path, load_avg represents the load average of _all_
the nodes. Have a look at find_busiest_node. Which jogs my memory of why
its not always a good idea to do your *imbalance min(...) thing (I actually
saw this happening).

5 CPUs, 4 processes running on one cpu. load_avg would be 0.8 for all cpus.
balancing doesn't happen. I have to think about this a bit more...


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/