linux-kernel - Re: [PATCH v3 2/2] sched/rt: Add check_preempt_equal_prio() logic in pick_next_task

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 12 Feb 2015 19:04:38 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Xunlei Pang <pang.xunlei@...aro.org>
Cc:	linux-kernel@...r.kernel.org,
	Peter Zijlstra <peterz@...radead.org>,
	Juri Lelli <juri.lelli@...il.com>
Subject: Re: [PATCH v3 2/2] sched/rt: Add check_preempt_equal_prio() logic
 in pick_next_task_rt()

On Sun,  8 Feb 2015 23:51:26 +0800
Xunlei Pang <pang.xunlei@...aro.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?

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

I'm sorry, I'm thinking this is trying too hard to fix the users poor
management of RT tasks.

If you have 2 or more RT tasks of the same prio, you had better be damn
aware that if one is pinned, it will block the others, even from
migrating. You should not have pinned tasks of the same prio as those
that can migrate.

And if your system depends on DL tasks working nicely with RT tasks on
the same CPU, it's even more broken by design.

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