Timer slack for slacker developers

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

and as a result of the possible misuse of this tool you (and others) appear utterly opposed to giving me, the administrator of a machine, any ability to override what the application programmers choose (or don't choose) to do.

for every scenario that someone paints where this could be useful, there is going to be another scenario where it could be misused.

but the same thing can apply to 'renice' or 'ionice' as well, why aren't you also opposed to the ability for the evil (or clueless) system administrator to mess with the application by changing it's priority.

or for that matter ulimit can cause programs to fail, it should be ripped out of the system, instead every applications should be audited to make sure it only allocates the resources that it really needs, and the applications should then be changed to cooperatively give up resources if something else needs it.

for that matter, what about preemptive time slicing, the system is more efficient if the applications cooperate instead, so we should just change every application to do cooperative time slicing, including setting the priority between applications (after all, doesn't the application writer know what's best for the applications)

why are all of these ways for an administrator to control what's happening with their machine acceptable, but the idea that the administrator could override the application's decision (or lack thereof) on timer slack be so horrible?

Timer slack for slacker developers

Posted Oct 18, 2011 9:28 UTC (Tue) by dgm (subscriber, #49227) [Link] (10 responses)

You're right. The fact that you _can_ do something doesn't mean you should, or will. But you may. And that means application writers and users _will_ pay a price for your flexibility: users complaining about broken applications because someone thought all applications should or should not do something.

Thus, I would say: if this gets finally in, advise to distributions and admins to NOT use it, unless you understand in gory detail ALL the implications. With great power... yada, yada, yada.

Frankly, I would add that using cgroups with this is calling for abuse. Make it a per process option and it will become much less "dangerous".

Timer slack for slacker developers

Posted Oct 18, 2011 14:18 UTC (Tue) by bronson (subscriber, #4806) [Link] (2 responses)

Why is it much less dangerous? What's the difference between the master app changing a cgroup and the master app looping through a list of children and changing them one by one?

Timer slack for slacker developers

Posted Oct 18, 2011 16:35 UTC (Tue) by dgm (subscriber, #49227) [Link]

The difference is that group membership is transitive. The children processes of your children (or of any other process added to the group) do belong to it by default. Knowing that all those processes will behave correctly is substantially more difficult than doing direct manipulation of a list of known processes.

Of course, if the group hierarchy is standardized, processes known to behave badly can be moved out of the group, but it would mean modification of the process, thus (at least partially) negating the benefits of being able to do it without changing code.

Timer slack for slacker developers

Posted Oct 18, 2011 16:56 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Race conditions. You need to be very sure that you haven't missed a child that has been created just after you've started looping.

cgroups allow to do it atomically.

Timer slack for slacker developers

Posted Oct 18, 2011 17:49 UTC (Tue) by dlang (guest, #313) [Link] (6 responses)

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