Re: [PATCH] hrtimers: Special-case zero length sleeps

[Thomas Gleixner <tglx@linutronix.de>]

On Thu, 16 Feb 2012, Matthew Garrett wrote:

> On Thu, Feb 16, 2012 at 03:51:16PM +0100, Peter Zijlstra wrote:
> > On Thu, 2012-02-16 at 14:31 +0000, Alan Cox wrote:
> > > 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?
> 
> Doing the right thing if practical. How about we special-case for now 
> with a once-per-process printk and kill it further down the line?

We've done this for stuff which was once kinda guaranteed
(intentionally or not), but sleep(0) has never had any guarantee
whatsoever. Quite the contrary it changed its behaviour several times
over the last decades and there is no reason to manifest some weird
ass semantics now.

> > 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?
> 
> The reason to change timer slack is because we're willing to break 
> polling applications in order to gain power savings. The problem is that 
> there are event-driven applications that are also going to be broken 
> because some ridiculous proportion of userspace believes that sleep(0) 
> is a thing that they can do in an event-driven application. The question 

If we are willing to break polling crap, then there is no fricking
reason not to break lousy programmed "event driven" crap while we are
at it.

> is whether the cost of special-casing that in the kernel is more than 
> fixing all of them.

The cost of special casing stuff is maintainence, inconsistance of
interfaces and extended confusion. And each of that is worse than
breaking some (i.e. 1% of the total app stack out there) weirdo apps.

> > What's next, we're actually going to give people their O_PONIES?
> 
> If we could give people O_PONIES then why wouldn't we? The only reason 
> not to is because it costs too much elsewhere.

Wrong. The reason is that O_PONIES is impossible to define and that's
equally true for any exception to the (nano)sleep interface.

Thanks,

	tglx