2008/4/23 Gregory Haskins <ghaskins@xxxxxxxxxx>: > Dmitry Adamushko pointed out a logic error in task_wake_up_rt() where we > will always evaluate to "true". You can find the thread here: > > http://lkml.org/lkml/2008/4/22/296 > > In reality, we only want to try to push tasks away when a wake up request is > not going to preempt the current task. So lets fix it. > > Note: We introduce test_tsk_need_resched() instead of open-coding the flag > check so that the merge-conflict with -rt should help remind us that we > may need to support NEEDS_RESCHED_DELAYED in the future, too. > > Signed-off-by: Gregory Haskins <ghaskins@xxxxxxxxxx> > CC: Dmitry Adamushko <dmitry.adamushko@xxxxxxxxx> Acked-by: Dmitry Adamushko <dmitry.adamushko@xxxxxxxxx> I have to look at the second patch more thoroughly... but I guess, we'd be better off opting for something more simple/less complex (it looks a bit heavy at the first glance). This patch already fixes an 'obvious' problem in task_wake_up_rt() and narrows down the scope of the original problem. For the original scenario (as well as for its variants with SCHED_FIFO and != priorities) push_rt_tasks() is 'delayed' untill a reschedule (which is already pending and should take place shortly... provided 'bounded/short' latencies :-) For T0,T1 having equal prios + SCHED_RR, T1 (which can't be migrated due to its affinity) will wait till T0's timeslice expires and for SCHED_FIFO -- till T0 releases a CPU. The 'optimal' way would be moving T0 immediatelly off this cpu. -- 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
