Re: [PATCH v3 2/2] sched/rt: Add check_preempt_equal_prio() logic in pick_next_task_rt()

From: Xunlei Pang
Date: Thu Feb 12 2015 - 23:40:44 EST

Hi Steve,

On 13 February 2015 at 11:55, Xunlei Pang <pang.xunlei@xxxxxxxxxx> wrote:
> Hi steve,
> On 13 February 2015 at 08:04, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
>> On Sun, 8 Feb 2015 23:51:26 +0800
>> Xunlei Pang <pang.xunlei@xxxxxxxxxx> 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at