The Linux Kernel Mailing List
 help / color / mirror / Atom feed
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 15:42:34 +0200	[thread overview]
Message-ID: <20160509134234.GZ3408@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <57308ABF.8020908@fau.de>

On Mon, May 09, 2016 at 03:03:59PM +0200, Maximilian Krüger wrote:
> 
> >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.

So barring the co-operative multitasking model (which is still somewhat
employed in places), sched_yield() is basically undefined except for
FIFO / DEADLINE.

Now, every OS does 'something', and we do too. But that something could
really include anything from nothing to setting pet on fire.

That said; there is a lot of crufty code out there that calls
sched_yield() for all sorts of reasons, but mostly bad ones.

I have seen code like:

	while (!event)
		sched_yield();

to wait for completion of 'event'. Now imagine what would happen if this
code ends up running at a real-time priority?

And, no, you really cannot say that will never happen as an application
developer, because the application user might start you with a different
scheduling class (for whatever reason), or the system might have
unconditional priority inheritance and you get caught in a boost chain,
or whatever.

The worst part is; we've had people reject patches when we fixed their
yield abuse for them :/

      reply	other threads:[~2016-05-09 13:42 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
2016-05-09 13:03   ` Maximilian Krüger
2016-05-09 13:42     ` Peter Zijlstra [this message]

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=20160509134234.GZ3408@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