Hi Steven, > [ ... ] > > 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. > > Ah, this may be what you are talking about. T0 was running, but because > T1 has its affinity set to cpu1 it wont cause a push. When T0 schedules > away to give T1 its cpu time, T0 wont push away because of the pushed > flag. > > Hmm, interesting. Of course my response is "Don't use SCHED_RR! It's > evil!" ;-) It's not just SCHED_RR ;-) They both can be of SCHED_FIFO. T1 _preempts_ T0 and again --> task_wake_up_rt() | ---> push_rt_tasks() -> rq->rt.pushed = 1 and T0 won't be pushed away to cpu0 by post_schedule_rt(). As Gregory has pointed out, at the very least it's a test in task_wake_up_rt() which is wrong. push_rt_tasks() should not be called when 'p' (a newly woken up task) is the next one to run. IOW, it should be (p->prio < rq->curr->prio) instead of (p->prio >= rq->rt.highest_prio). -- 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
