linux-kernel - Re: [RFC] sched: low latency feedback to userspace

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]

Message-ID: <57308ABF.8020908@fau.de>
Date:	Mon, 9 May 2016 15:03:59 +0200
From:	Maximilian Krüger <maximilian.krueger@....de>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC] sched: low latency feedback to userspace


> 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