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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
