Re: [PATCH 3/3] sched: terminate newidle balancing once at least one task has moved over

[Nick Piggin <nickpiggin@yahoo.com.au>]

On Tuesday 24 June 2008 11:07, Steven Rostedt wrote:
> On Tue, 24 Jun 2008, Nick Piggin wrote:
> > On Tuesday 24 June 2008 09:04, Gregory Haskins wrote:
> > > Inspired by Peter Zijlstra.
> >
> > Is this really getting tested well? Because at least for SCHED_OTHER
> > tasks, the newidle balancer is still supposed to be relatively
> > conservative and not over balance too much. By the time you have
> > done all this calculation and reached here, it will be a loss to only
> > move one task if you could have moved two and halved your newidle
> > balance rate...
>
> We've been finding a lot of our high latencies have been coming from the
> balancing code. And the newidle balance is a large offender. I don't think

Measurements and results weren't in the changelog.

> it's much wasted work for what you want. Even if we wasted the work done,
> it was during "idle" time.

It is idle because it has gone idle. If we pulled more tasks in the last
newidle balance, it wouldn't have gone idle so early.

> But now we have a task to run, why not run it 
> now. Especially if that task is an RT task and doesn't like to wait.

Maybe I would agree if you check for an -rt task rather than generally.
At this level, throughput is the major concern for many more Linux users
than latency.


> The newidle balance should really just get a task to run, the balancing
> code should be done at a later time. Ideally when no RT tasks need to run.

I disagree. All balancing should be minimised, but if it has to run
then it should do as much balancing as it can. We already have checked
several other runqueues and calculated the busiest one  etc etc.