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] [day] [month] [year] [list]

Date:	Fri, 15 Feb 2013 08:37:02 -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 Fri, 2013-02-15 at 12:51 +0100, Peter Zijlstra wrote:
> On Wed, 2013-02-13 at 14:05 -0500, Steven Rostedt wrote:

> Ah, so that's push_rt_task() which wants to move extra rt tasks to other
> cpus. Doing that from where we have idle_balance() won't actually work I
> think since we might need to move current, which we cannot at that point
> -- I'm thinking a higher prio task (than current) waking to this cpu and
> then cascading current to another cpu, can that happen?

Yep, that's exactly why we do the push after the switch. It also catches
a bunch of races that can happen if in the middle of the switch another
CPU drops in priority. A drop in priority can cause that CPU to search
for pending rt tasks on other CPUs, but because current hasn't been
taken off the queue yet, it can miss trying to pull it, and current
could get stuck on its CPU even though there's another CPU it could run
on. Having the higher priority task do the check solves that race.

> 
> If we never need to migrate current because we don't do the cascade by
> ensuring we wake the higher prio task to the approriate cpu we might
> just get away with it.

I'm not exactly sure what you mean by this? Migrate the higher task? But
what if it's pinned. And we use to do that, until we found out that
higher priority tasks were ping-ponging around like crazy.

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