Hi Steve, On 13 February 2015 at 11:55, Xunlei Pang <pang.xun...@linaro.org> wrote: > Hi steve, > > On 13 February 2015 at 08:04, Steven Rostedt <rost...@goodmis.org> wrote: >> On Sun, 8 Feb 2015 23:51:26 +0800 >> Xunlei Pang <pang.xun...@linaro.org> wrote: >> >>> check_preempt_curr() doesn't call sched_class::check_preempt_curr >>> when the class of current is a higher level. >> >> The above sentence does not make sense. >> >>> So if there is a DL >>> task running when doing this for RT, check_preempt_equal_prio() >> >> Doing what for RT? >> >>> will definitely miss, which may result in some response latency >> >> Miss what? > > Sorry, this may lack some information I need to further explain in detail. > >> >>> for this RT task if it is pinned and there're some same-priority >>> migratable rt tasks already queued. >>> >>> We should do the similar thing in select_task_rq_rt() when first >>> picking rt tasks after running out of DL tasks. >>> >>> This patch tackles the issue by peeking the next rt task(RT1), and >>> if find RT1 migratable, just requeue it to the tail of the rq using >>> requeue_task_rt(rq, p, 0). In this way: >>> - If there do have another rt task(RT2) with the same priority as >>> RT1, RT2 will finally be picked as the running task. While RT1 >>> will be pushed onto another cpu via RT1's post_schedule(), as >>> RT1 is migratable. The difference from check_preempt_equal_prio() >>> here is that we just don't care whether RT2 is migratable. >>> >>> - Otherwise, if there's no rt task with the same priority as RT1, >>> RT1 will still be picked as the running task after the requeuing. >> >> What happens if there's three RT tasks of the same prio, RT1 is ready >> to run and is migratable, RT2 is pinned, RT3 is migratable >> >> RT1 just got pushed behind RT3 and it is now not the next one to run. >> RT2 will get this rq, RT3 will be pushed off, but say there's no more >> rq's available to run RT1. >> >> You just broke FIFO. > > Yes, I've also thought of this point before. > > If this is a problem, we may have the same thing happening in > current check_preempt_equal_prio() code: > When a pinned waking task preempts the current successfully, > because it thinks current is migratable via cpupri_find(). > > But when resched happens, things may change, i.e. current > becomes non-migratable, so the waking task gets running, while > the previous running task gets stuck. See, it also broke FIFO.
Aside of this, please ignore this patch, the waking rt tasks will also be pushed via task_woken_rt() when current is DL, which I missed before. Thanks, Xunlei -- 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/
