Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
I think the default should be 'illimited' indeed, and changeable at run time via proc or sys, so everyone can make their choice.
SCHED_FIFO and realtime throttling
Posted Sep 2, 2008 13:46 UTC (Tue) by jamesh (guest, #1159)
Posted Sep 2, 2008 15:48 UTC (Tue) by IkeTo (subscriber, #2122)
Should polling hardware be the task of the kernel, especially if it is so sensitive to timing?
> I think the default should be 'illimited' indeed, and changeable at run
> time via proc or sys, so everyone can make their choice.
If "everyone can make their choice" anyway, why not have the default to be limited to a sensible value so that the choice to betray themselves are made only consciously?
Be reminded that people (distributions) do use SCHED_FIFO, e.g., to play movie in a way that video hopefully sync with audio. It isn't nice if such programs would "normally" be risky of getting their computers hung up.
Posted Sep 2, 2008 19:38 UTC (Tue) by k8to (subscriber, #15413)
Let's say I have the software to run a robot implemented in Linux. My route plotting software is implemented in userland, and I've carefully written it so that it has a worst case time to reroute the robot in 50ms in an emergency, so it will never collide with a human.
Oops, my cpu got yanked away from me in the middle of that and now I ran someone over.
Posted Sep 2, 2008 21:46 UTC (Tue) by dlang (✭ supporter ✭, #313)
besides, if you are building your super-fast robot control system you have the ability to turn the knob and give yourself absolute control of the CPU
Posted Sep 2, 2008 22:13 UTC (Tue) by nix (subscriber, #2304)
I'd also say that this is an extremely rare case: most Linux users are not
working on systems that can harm people if held up for a fraction of a
second. The needs of the overwhelmingly common case (`don't let buggy code
lock up my system') should govern.
Posted Sep 3, 2008 2:26 UTC (Wed) by walken (subscriber, #7089)
Posted Sep 4, 2008 8:26 UTC (Thu) by ekj (guest, #1524)
In other words, they claim that -MOST- peoples machines are probably better of in MOST cases letting a gone-crazy SCHED_FIFO process hog only 95% of the cpu, rather than 100. Because it makes it possible to for example open a shell and kill the bugger.
The existence of special rare cases where you really want 100% is a no-argument: Simply *turn* the provided knob up to 100 for those cases then.
You're in essence saying that 99% of users should turn the knob down to 95 - so that the last 1% won't have to turn it up to 100. Which makes no sense.
Also, your example is extremely contrived. Indeed it serves as a good example of just how uncommon such situations are likely to be.
Posted Sep 5, 2008 7:26 UTC (Fri) by rvfh (subscriber, #31018)
But the issue here is not just 'what is best for most people' but also 'what's expected from the spec'. Breaking the spec is exactly what we reproach to some companies, and we need to think carefully before doing it.
I guess that's why Linus himself did not take party, and that's why I don't really know which is best either, but reading the comments here makes me think that I would rather have the 90% myself :-)
Posted Sep 5, 2008 12:10 UTC (Fri) by ekj (guest, #1524)
The overwhelming majority of machines should be configured so that a bug in a single SCHED_FIFO priority task cannot completely lock the machine up hard.
That makes it a sensible default in my book.
Okay okay, so you can argue the KERNEL should default to 100%, whereupon 99% of the distributions out there should default to turning the knob to 95% or 90% or whatever.
But -someone-, earlier in the chain than the end-user, should change their default. It's not reasonable (as today!) to expect Joe User to know that he needs to turn the knob to avoid hard lockups on stumbling on a pulseaudio-bug or whatever.
I still think the extremely few projects that DO need true 100% can turn the knob themselves; are you aware of even a single real such project ? (as opposed to theoretical constructs like the one in the grandparent)
Posted Sep 4, 2008 11:19 UTC (Thu) by mb (subscriber, #50428)
Posted Sep 8, 2008 0:53 UTC (Mon) by vonbrand (subscriber, #4458)
Part of the whole idea is getting rid on RTLinux (i.e., integrating that functionality into the vanilla kernel source).
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds