linux-kernel - Re: [PATCH 2/3] sched: Move idle_balance() to post

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]

Message-ID: <1360782338.23152.22.camel@gandalf.local.home>
Date:	Wed, 13 Feb 2013 14:05:38 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Mike Galbraith <efault@....de>
Subject: Re: [PATCH 2/3] sched: Move idle_balance() to post_schedule

On Wed, 2013-02-13 at 19:43 +0100, Peter Zijlstra wrote:
> On Tue, 2013-02-12 at 17:54 -0500, Steven Rostedt wrote:
> > There's no real reason that the idle_balance() needs to be called in
> > the
> > middle of schedule anyway. The only benefit is that if a task is
> > pulled
> > to this CPU, it can be scheduled without the need to schedule the idle
> > task. 
> 
> Uhm, istr that extra schedule being an issue somewhere.. Make very sure
> you don't regress anything silly like sysbench or hackbench. Maybe ask
> Mike, he seems to have a better retention for benchmark weirdness than
> me.

I'm all for benchmarks :-)

> 
> > But load balancing and migrating the task makes a switch to idle
> > and back negligible.
> 
> How does that follow? We can have to-idle switches _far_ more often than
> we balance.

But we have the to-idle switch regardless in that case, don't we?

That is, the CPU is about to go idle, thus a load balance is done, and
perhaps a task is pulled to the current queue. To do this, rq locks and
such need to be grabbed across CPUs.

If it didn't balance the switch would happen anyways.

The current method is:

	if (!rq->nr_running)
		idle_balance();

	/* if something pulled, then run that instead,
	   if not, continue to switch to idle. */

What this change did was:

	pick_next_task_idle()
		rq->post_schedule = 1;

	post_schedule()
		idle_balance();

Now if a balance occurred, we would have to switch back from idle, to
what we just pulled.

Hence the change is that a switch to and from idle is done only in the
case that load balancing occurred, otherwise it just goes to idle like
it always has.

Or perhaps I need add another check to make sure rq->nr_running is still
0 before doing the balance, because the rq lock was released. That is:

	post_schedule()
		if (!rq->nr_running)
			idle_balance();

needs to be added.

-- Steve



--
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/