Re: [RFC] sched: low latency feedback to userspace
From: Maximilian KrÃger
Date: Mon May 09 2016 - 09:04:10 EST
sched_yield() for anything other than SCHED_FIFO / SCHED_DEADLINE is a
'bug'. That is, calling sched_yield() outside of those two cases is
undefined behaviour and the kernel is free to eat your granny and set
your pet on fire.
okay, fair.c/yield_task_fair() does not exactly sound, as if it would
set my granny on fire or eat my pet, nor does man 2 yield, but correct
me if I'm wrong.
Schemes like this have been proposed many times (Google might find them
for you in your favourite LKML archive) and shot down the same number of
times.
Such proposals always end up needing to define a 'limit', which is
artificial and subject to creep, also such soft preempt-disable or boost
schemes have very open ended semantics. They also become useless if
_everyone_ requests them at the same time -- something not unlikely
since every userspace program thinks it is the most important thing
under the sun.
I'm totally with you in this point, which is, why I under no
circumstances will prevent
preemption or sacrifice the scheduler fairness, so these tasks might run
longer uninterrupted, even though this still is up to discussion. Which
is, why I would argue, that there would not be a benefit for tasks to
use this, just because they think that they are more important than
anyone else.
Would something like:
http://lkml.kernel.org/r/20151027235635.16059.11630.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
and
http://lkml.kernel.org/r/1459789313-4917-1-git-send-email-mathieu.desnoyers@xxxxxxxxxxxx
work for what you want to achieve? If not; please explain in more detail
why you want what you propose.
the second patchset actually looks useful to me, but I very much agree
with the comments, that this thing looks overly complicated. So yes, the
interface I have in mind will be similar on an abstract level, but I
don't intend any generic interface or anything close to this complexity.
thanks for the the quick feedback,
Max