SCHED_FIFO and realtime throttling [LWN.net]

SCHED_FIFO and realtime throttling

Posted Sep 4, 2008 8:26 UTC (Thu) by ekj (guest, #1524)
In reply to: SCHED_FIFO and realtime throttling by k8to
Parent article: SCHED_FIFO and realtime throttling

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.

(Log in to post comments)

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)