Re: [RFC] sched: low latency feedback to userspace

["Maximilian Krüger" <maximilian.krueger@fau.de>]

> 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@pjt-glaptop.roam.corp.google.com
>
> and
>
>    http://lkml.kernel.org/r/1459789313-4917-1-git-send-email-mathieu.desnoyers@efficios.com
>
> 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