User: Password:
|
|
Subscribe / Log in / New account

SCHED_FIFO and realtime throttling

SCHED_FIFO and realtime throttling

Posted Sep 2, 2008 19:38 UTC (Tue) by k8to (subscriber, #15413)
In reply to: SCHED_FIFO and realtime throttling by IkeTo
Parent article: SCHED_FIFO and realtime throttling

You don't have to resort to hardware to make this important.

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.


(Log in to post comments)

SCHED_FIFO and realtime throttling

Posted Sep 2, 2008 21:46 UTC (Tue) by dlang (subscriber, #313) [Link]

if a few ms (or even a couple hundred ms) make the difference between avoiding a human and crashing into one you must have a pretty fast robot!

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

SCHED_FIFO and realtime throttling

Posted Sep 2, 2008 22:13 UTC (Tue) by nix (subscriber, #2304) [Link]

If your super-fast robot control system is capable of running people over,
I'd say you're negligent if you don't find and turn that knob (and a good
few extra ones).

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.

SCHED_FIFO and realtime throttling

Posted Sep 3, 2008 2:26 UTC (Wed) by walken (subscriber, #7089) [Link]

I think your hypothetical robot controller should arrange to be scheduled to run, at a high priority, every 10ms or so. It'd check that there is no emergency, and then it'd sleep for the next 10ms.

SCHED_FIFO and realtime throttling

Posted Sep 4, 2008 8:26 UTC (Thu) by ekj (guest, #1524) [Link]

Irrelevant. They're only talking of changing the DEFAULT, not of making giving up up to 5% cpu MANDATORY.

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.

SCHED_FIFO and realtime throttling

Posted Sep 5, 2008 7:26 UTC (Fri) by rvfh (subscriber, #31018) [Link]

I perfectly understand that, for most people, 95% or even 90% is best.

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 :-)

SCHED_FIFO and realtime throttling

Posted Sep 5, 2008 12:10 UTC (Fri) by ekj (guest, #1524) [Link]

In general, providing sensible defaults is a good thing.

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)

SCHED_FIFO and realtime throttling

Posted Sep 4, 2008 11:19 UTC (Thu) by mb (subscriber, #50428) [Link]

You should be using rtai or rtlinux, if you have such requirements.
Yeah, really, you should.

http://linuxcnc.org/

SCHED_FIFO and realtime throttling

Posted Sep 8, 2008 0:53 UTC (Mon) by vonbrand (guest, #4458) [Link]

Part of the whole idea is getting rid on RTLinux (i.e., integrating that functionality into the vanilla kernel source).


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds