Timer slack for slacker developers

Posted Oct 18, 2011 17:49 UTC (Tue) by dlang (guest, #313)
In reply to: Timer slack for slacker developers by dgm
Parent article: Timer slack for slacker developers

why is this option for cgroups any more dangerous than cpu, memory, or disk I/O throttling?

in all cases you can cause an application being limited to behave in ways different from what the application programmer expected.

Timer slack for slacker developers

Posted Oct 18, 2011 21:40 UTC (Tue) by cmccabe (guest, #60281) [Link] (5 responses)

Operating systems certainly need to have configuration knobs. nice, ionice, ulimit, and friends definitely fall into this category. But the more configuration knobs you have, the more complex the system gets to administer, to understand, and to program for. Complexity tends to breed bugs, frustrated users, and miscommunication between different subsystems. That is why adding a new knob just to do something that you could have done with the old knobs is something that we should resist.

nice and ulimit are also things specified by POSIX and implemented by many other operating systems. Like Linus said, Linux-specific interfaces tend not to get very much use, even when they're much better than the standard interfaces they're replacing. In this case, you're talking about adding a platform specific interface that is not better than what it's replacing, just different. It's also an interface that application developers have no easy way to opt-out of. IMHO, not a win at all.

Timer slack for slacker developers

Posted Oct 18, 2011 22:23 UTC (Tue) by dgm (subscriber, #49227) [Link] (2 responses)

Not onyl that. This particular know is for making timers misbehave in order to save power. An application can be expected to work with less CPU or IO, but faulting timers?

Timer slack for slacker developers

Posted Oct 18, 2011 22:37 UTC (Tue) by dlang (guest, #313) [Link] (1 responses)

remember that timers are not precise. they will delay you until _at_least_ the timer wakeup, they may delay you further.

normally this further amount is relatively short, but if the system is under high load it could be a significant amount of time (if the system is swapping badly, it could be seconds after the timer is scheduled to fire before the application executes)

this is just changing things to that some other suitably privileged task in the system can increase the maximum lag that the application sees.

it's not something that can't happen today.

Timer slack for slacker developers

Posted Oct 19, 2011 13:39 UTC (Wed) by dgm (subscriber, #49227) [Link]

You're completely right, of course. I'm sold.

Timer slack for slacker developers

Posted Oct 18, 2011 22:33 UTC (Tue) by dlang (guest, #313) [Link] (1 responses)

in this case, short of modifying the source code (not something for an administrator to do), what current knob do you have to be able to change the timer slack for another process (or group of processes)?

as I see it there is no knob that you (as an administrator) can twist for this today.

there's also no knob that you as a application programmer can twist that will change the slack for you and your running children, instead you would have to have each child invoke the change independently.

Timer slack for slacker developers

Posted Oct 19, 2011 2:08 UTC (Wed) by cmccabe (guest, #60281) [Link]

Application programmers can do things like increase timeouts for background threads or (often) avoid polling entirely. Lennart email talks about "stuff like closed source crap, and all kinds of other things you cannot fix." One very common novice programmer mistake is using polling where you don't need to.

The one use case that is intriguing is synchronizing application timers so that a lot of them fire at once, in order to save on wakeups. I honestly can't think of any good way to do this with the existing timeout APIs-- maybe someone else can.

All these comments about "slack" are making me think of this guy:
http://en.wikipedia.org/wiki/File:Bobdobbs.png