Date:	Sun, 26 Apr 2015 11:58:51 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	pang.xunlei@....com.cn
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Juri Lelli <juri.lelli@...il.com>,
	linux-kernel@...r.kernel.org, linux-kernel-owner@...r.kernel.org,
	Xunlei Pang <pang.xunlei@...aro.org>
Subject: Re: [PATCH v6 2/3] sched/rt: Fix wrong SMP scheduler behavior for
 equal prio cases

On Sun, 26 Apr 2015 17:52:16 +0800
pang.xunlei@....com.cn wrote:
 
> The problem I tried to describe here is:
> 
> We know, there are two main queues each cpu for RT scheduler: 
> "run queue" and "pushable queue".
>  
> For RT tasks, the scheduler uses "plist" to manage the pushable queue,
> so when there are multiple tasks queued at the same priority, they get 
> queued in the FIFO order.
> 
> Currently, when an rt task gets queued, it is put to the head or the
> tail of its "run queue" according to different scenarios. Then if it 
> is migratable, it will also and always be put to the tail of its 
> "pushable queue".
> 
> For one cpu, assuming initially it has multiple migratable tasks queued 
> at the same priority as current(RT) in "run queue" and "pushable queue" 
> both in the same order. At some time, when current gets preempted, it 
> will be put behind these tasks in the "pushable queue", while it still 
> stays ahead of these tasks in the "run queue". Afterwards, if there comes 
> a pull from other cpu or a push from local cpu, the task behind current 
> in the "run queue" will be pulled from the "pushable queue" and gets 
> running.
> 
> Obviously, to maintain the same order between the two queues, when current 
> 
> is preempted(not involving re-queue in the "run queue"), we want to put it 
> 
> ahead of all those tasks queued at the same priority in the "pushable 
> queue".
> 
> -Xunlei


I think what Xunlei is trying to say, is that we don't currently keep
FIFO when preemption or migration is involved. If a task is currently
running, strict FIFO denotes that it should run ahead of all other
tasks queued at its priority or less until it decides to schedule out.
But the issue is, if it gets preempted or migrates, it gets placed
behind other tasks of the same priority as itself, but it never
voluntarily relinquished the CPU.

Thus, if it gets preempted by a higher priority task, it should at a
minimum be placed ahead of all other tasks of its priority or less to
run on the CPU again. If it gets migrated to another CPU, it should at
least be placed ahead of other tasks on that new CPU of the same
priority. Although, for the migration case, I'm not sure why it would
be migrated to a CPU where it couldn't run right away in the first
place, as the push/pull logic only migrates RT tasks that can run on
the new CPU. Unless, he's talking about a race where a new task just
got scheduled before it made it to the CPU? But that's a separate issue.

But at least for being preempted by a higher priority task, it should
be placed back ahead of the currently running tasks, unless it did a
yield or is RR and its time ran out.

I'm not sure why your solution with yield_task_rt() and task_tick_rt()
doesn't work. Maybe Xunlei is looking too deep into the solution.
Monday, I'll try to spend some time looking at the scheduler logic
there.

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

Powered by blists - more mailing lists