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 it's much wasted work for what you want. Even if we wasted the work done, it was during "idle" time. 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. 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. -- Steve > > > Signed-off-by: Gregory Haskins <ghaskins@xxxxxxxxxx> > > --- > > > > kernel/sched.c | 4 ++++ > > 1 files changed, 4 insertions(+), 0 deletions(-) > > > > diff --git a/kernel/sched.c b/kernel/sched.c > > index 3efbbc5..c8e8520 100644 > > --- a/kernel/sched.c > > +++ b/kernel/sched.c > > @@ -2775,6 +2775,10 @@ static int move_tasks(struct rq *this_rq, int > > this_cpu, struct rq *busiest, max_load_move - total_load_moved, > > sd, idle, all_pinned, &this_best_prio); > > class = class->next; > > + > > + if (idle == CPU_NEWLY_IDLE && this_rq->nr_running) > > + break; > > + > > } while (class && max_load_move > total_load_moved); > > > > return total_load_moved > 0; > > > > -- > -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html