On 06/10/20 14:48, Peter Zijlstra wrote: > On Tue, Oct 06, 2020 at 12:20:43PM +0100, Valentin Schneider wrote: >> >> An alternative I could see would be to prevent those piles from forming >> altogether, say by issuing a similar push_cpu_stop() on migrate_disable() >> if the next pushable task is already migrate_disable(); but that's a >> proactive approach whereas yours is reactive, so I'm pretty sure that's >> bound to perform worse. > > I think it is always possible to form pileups. Just start enough tasks > such that newer, higher priority, tasks have to preempt existing tasks. > > Also, we might not be able to place the task elsewhere, suppose we have > all our M CPUs filled with an RT task, then when the lowest priority > task has migrate_disable(), wake the highest priority task. > > Per the SMP invariant, this new highest priority task must preempt the > lowest priority task currently running, otherwise we would not be > running the M highest prio tasks. >
Right, and it goes the other way around for the migrate_disable() task: if it becomes one of the M highest prio tasks, then it *must* run, and push/pulling its CPU's current away is the only way to do so... > That's not to say it might not still be beneficial from trying to avoid > them, but we must assume a pilup will occur, therefore my focus was on > dealing with them as best we can first. "Funny" all that... Thanks!
