Re: SD_SHARE_CPUPOWER breaks scheduler fairness

[Con Kolivas <kernel@kolivas.org>]

On Thu, 2 Jun 2005 23:30, Steve Rotolo wrote:
> > > Wild thought: how about doing this for the sibling ...
> > >
> > > 	rp->nr_running += SOME_BIG_NUMBER
> > >
> > > when a SCHED_FIFO task starts running on some cpu, and
> > > undo the above when the cpu is released.   This fools
> > > the load balancer into _gradually_ moving tasks off the
> > > sibling, when the cpu is hogged by some SCHED_FIFO task,
> > > but should have little effect if a SCHED_FIFO task takes
> > > little cpu time.
> >
> > A good thought, and one I had considered. SOME_BIG_NUMBER needs to be
> > meaninful for this to work. Ideally what we do is add the effective load
> > from the sibling cpu to the pegged cpu. However that's not as useful as
> > it sounds because we need to ensure both sibling runqueues are locked
> > every time we check the load value of one runqueue, and the last thing I
> > want is to introduce yet more locking. Also the value will vary wildly
> > depending on whether the task is pegged or not, and this changes in
> > mainline many times in less than .1s which means it would throw load
> > balancing way off as the value will effectively become meaningless.
>
> Just a few more thoughts on this....
>
> I can't help but wonder if a similar problem exists even without HT.
> What if the load-balancer decides to keep a sched_normal task on a cpu
> that is being dominated by a sched_fifo task.  The sched_normal task
> should really be "balanced" to a different cpu but because nr_running is
> the only balancing criteria that may not happen.  Runqueue business
> ought to be weighted by the amount of time that sched_fifo tasks on that
> runqueue have recently used.  So, load = rq->nr_running +
> rq->recent_fifo_run_time.  I think this would make load-balancing more
> correct.

Funny you should mention this. Check the latest -mm code and you'll see Andrew 
has merged my smp nice code which takes into account "nice" values and alters 
balancing according to nice values and heavily biases them when real time 
tasks are running. So you are correct, and it is a problem common to any 
per-cpu runqueue designed scheduler (which interestingly there is evidence 
that windows went to in about 2003 because it exhibited this very problem). 
However my code should make this behave better now.

Cheers,
Con

Attachment: pgpi5FvcxlPMp.pgp
Description: PGP signature