From: Peter Zijlstra <peterz@infradead.org>
To: "Maximilian Krüger" <maximilian.krueger@fau.de>
Cc: Ingo Molnar <mingo@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: [RFC] sched: low latency feedback to userspace
Date: Mon, 9 May 2016 13:18:31 +0200 [thread overview]
Message-ID: <20160509111831.GY3408@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <5730640E.9050503@fau.de>
On Mon, May 09, 2016 at 12:18:54PM +0200, Maximilian Krüger wrote:
> I am planning to extend the CFS as part of my master thesis. I want
> user-threads to allow to decide whether to enter a critical section or call
> sched_yield()
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.
> For tight synchronized workloads it might be useful, to only start certain
> short tasks, when they still can be completed in the current time slice
> without being interrupted by the scheduler.
> Since low latency is key, my current plan is to use a shared-mapped page for
> signaling and only use a syscall for the setup. I'd be curious, if you might
> find this useful in general and if there is a chance for getting this
> accepted upstream, given my benchmarks can prove gives the intended
> benefits.
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.
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.
next prev parent reply other threads:[~2016-05-09 11:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-09 10:18 [RFC] sched: low latency feedback to userspace Maximilian Krüger
2016-05-09 11:18 ` Peter Zijlstra [this message]
2016-05-09 13:03 ` Maximilian Krüger
2016-05-09 13:42 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160509111831.GY3408@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maximilian.krueger@fau.de \
--cc=mingo@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox