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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 24 Jun 2008 11:26:28 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Gregory Haskins <ghaskins@...ell.com>, mingo@...e.hu,
	tglx@...utronix.de, linux-kernel@...r.kernel.org,
	peterz@...radead.org, linux-rt-users@...r.kernel.org,
	dbahi@...ell.com
Subject: Re: [PATCH 3/3] sched: terminate newidle balancing once at least one task has moved over

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