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

[Steven Rostedt]

On Fri, 13 Feb 2015 11:55:11 +0800
Xunlei Pang <pang.xunlei@xxxxxxxxxx> wrote:

> > 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.

It breaks FIFO if the state of the system changes before the current
task found another queue to run on, sure, and that probably should be
fixed. And technically, that case does not break FIFO from a state
point of view. Think of the timing, if that task was able to migrate to
another CPU, but suddenly it could not, that means the CPU it was going
to migrate to had a higher priority task that started to run on that
CPU. It still fits the FIFO design. That's because if that task
succeeded to migrate to that CPU, just before the high priority task
ran, that high priority task would have bumped it anyway.

Now if it couldn't migrate because a same priority task started, then,
well yeah, it broke FIFO, and maybe that should be fixed.

But your patch breaks FIFO if the system is in just one
particular state. That's much worse, and it shouldn't be added.

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/