Hi Gregory, consider the following 2-cpu system: cpu0 and cpu1. cpu0: is idle --> in such a state, it never pulls RT tasks on its own. T0 and T1 are RT tasks square#0: cpu1: T0 is running T1 is of the same prio as T0 (shouldn't really matter but to get the same result it would require altering the flow of events slightly) T1's affinity allows it to be run only on cpu1. T0 can run on both. try_to_wake_up() is called for T1. | --> select_task_rq_rt() => gives cpu1 | --> task_wake_up_rt() | ---> push_rt_tasks() -> rq->rt.pushed = 1 now, neither T1 (due to its affinity), nor T0 (it's running) can be pushed away to cpu0. [ btw., (1) I'd expect that this task_wake_up_rt() thing should be redundant, logically-wise... I'll check once more and comment later on. (2) any example when (p->prio >= rq->rt.highest_prio) is not true in task_wake_up_rt() ? ] as a result, rq->rt.pushed == 1. Now, post_schedule_rt() won't call push_rt_tasks(). T0 and T1 are both running for some time on cpu1 (possibly context-switching if they are both of SCHED_RR type). Then they both block, _first_ T1 and then T0. After some interval of time, they wake up (let's say they are periodic) in the following order: _first_ T0 and then T1. rq->rt.pushed becomes 0 and here we are back to square#0. The whole story repeats again. cpu0 is idle so it won't pull T0. Both T0 and T1 are competing for the same cpu. Not good. am I missing smth? -- Best regards, Dmitry Adamushko -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
