public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>,
	Arjan van de Ven <arjan@infradead.org>
Subject: Re: [PATCH] hrtimers: Special-case zero length sleeps
Date: Thu, 16 Feb 2012 15:51:16 +0100	[thread overview]
Message-ID: <1329403876.2293.232.camel@twins> (raw)
In-Reply-To: <20120216143132.293c8f50@pyramind.ukuu.org.uk>

On Thu, 2012-02-16 at 14:31 +0000, Alan Cox wrote:
> > Userspace clearly has an expectation that sleep(0) is magic in some 
> > ill-defined way. We'd be well within our rights to break that 
> > expectation, but I think it's common enough to warrant special casing.
> 
> In historical Unix sleep(0) ends up the nearest equivalent it had to
> triggering a reschedule and giving up the rest of the timeslice.
> 
> I suspect special casing it as yield() isn't far from the right result ?

But why go that way? Using sleep(0) or yield() is pretty much always the
wrong thing to do anyway, this is a great opportunity for all folks to
find these sites and fix them.

Wasn't that what open-source is all about, doing the right thing?

Why should we care about obviously broken crap?

Furthermore, pushing slack to several seconds will also break stuff that
needed those timers to expire sooner, who is going to fix that?

So we've got a stacking of two ill-considered things:
 - applications using yield()/sleep(0)
 - weirdos pushing timer slack to the seconds range

Individually both cause/are borkage, and now you want to add code to the
kernel to mitigate some, but nowhere near all, of it?

What's next, we're actually going to give people their O_PONIES?



  reply	other threads:[~2012-02-16 14:51 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-29 14:59 [PATCH] hrtimers: Special-case zero length sleeps Matthew Garrett
2012-02-15 14:40 ` Thomas Gleixner
2012-02-15 14:52   ` Matthew Garrett
2012-02-15 20:14     ` Thomas Gleixner
2012-02-15 20:22       ` Matthew Garrett
2012-02-15 20:30         ` Thomas Gleixner
2012-02-15 20:38           ` Matthew Garrett
2012-02-15 20:40             ` Peter Zijlstra
2012-02-15 20:43               ` Matthew Garrett
2012-02-15 20:46             ` Thomas Gleixner
2012-02-15 20:47               ` Matthew Garrett
2012-02-16 14:27                 ` Matthew Garrett
2012-02-16 14:31                   ` Alan Cox
2012-02-16 14:51                     ` Peter Zijlstra [this message]
2012-02-16 15:01                       ` Matthew Garrett
2012-02-16 19:09                         ` Thomas Gleixner
2012-02-15 14:54   ` Peter Zijlstra
2012-02-15 14:58     ` Matthew Garrett
2012-02-15 20:22       ` Thomas Gleixner

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=1329403876.2293.232.camel@twins \
    --to=peterz@infradead.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arjan@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjg59@srcf.ucam.org \
    --cc=tglx@linutronix.de \
    /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