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

[Matthew Garrett]

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?

> 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 
is whether the cost of special-casing that in the kernel is more than 
fixing all of them.

> 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?

If we could give people O_PONIES then why wouldn't we? The only reason 
not to is because it costs too much elsewhere.

-- 
Matthew Garrett | mjg59@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/