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

SCHED_FIFO and realtime throttling

SCHED_FIFO and realtime throttling

Posted Sep 2, 2008 22:07 UTC (Tue) by nix (subscriber, #2304)
In reply to: SCHED_FIFO and realtime throttling by ballombe
Parent article: SCHED_FIFO and realtime throttling

But the problem is that it's the *processes* that decide whether to use
SCHED_FIFO or this new _THROTTLED variant. If I wanted to impose a site
policy that no process is allowed to lock up my system by taking total
ownership of the CPU forever, even if it wants to, I'd have to change the
source of every application that used SCHED_FIFO, and if it was
closed-source I'd be out of luck.

And that's not good enough. Regardless of what the default is, I want some
way to say 'let realtime-prio stuff run without scaring me', and that
means they take most, but not all of the CPU. (What's the difference
between a process taking most of the CPU and one taking all of it on a
slightly slower machine? A process, realtime or not, that cares that it's
running 5% slower than otherwise is a broken process --- just like one
that hogs the CPU constantly for ten seconds and doesn't let anyone else
get a word in edgeways.)

(This is particularly important now that RT-prio stuff can run as
non-root, because that means it might actually get used for
non-specialized applications, not all of which can be guaranteed not to
have infloop-causing bugs.)


(Log in to post comments)

SCHED_FIFO and realtime throttling

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

> (What's the difference between a process taking most of the CPU and one
> taking all of it on a slightly slower machine? A process, realtime or not,
> that cares that it's running 5% slower than otherwise is a broken process
> --- just like one that hogs the CPU constantly for ten seconds and doesn't
> let anyone else get a word in edgeways.)

The process running 100% of the time on a slow machine will see time progress in small increments (say, if it calls gettimeofday in a loop, it'll see it progress a few microseconds at a time) while the process running 95% on a fast machine will see a large time increment once in a while, when it is descheduled. So, there definitely is a difference, for realtime processes.

Still, I do not understand why one would try to yank 100% of the CPU on a posix system and expect the underlying OS to work fine...

SCHED_FIFO and realtime throttling

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

Yeah well, a hard (old style) RT process will also be interrupted once in a while by hardware interrupts. Sure, the time running an IRQ is a lot lower than the time a process is scheduled away, but still.
If you really care about not getting interrupted at all, you should be running inside of the kernel or probably with rtai or rtlinux.

SCHED_FIFO and realtime throttling

Posted Sep 5, 2008 10:27 UTC (Fri) by dmarkh (guest, #40670) [Link]

The thing is anyone actually having a dedicated machine to run that (old style) RT process is almost surely running on an SMP machine and has isolated his CPU from hardware interrupts and other processes. But even doing that, the kernel thinks that IT owns the CPUs in your box, not you, and requires some time on YOUR cpu regardless of your requirements. Folks, the kernel is just plain broken when you have 4 processors and cannot dedicate %100 of a single processor for a RT application. When you run a process at %100 on a single processor it breaks the kernel because the kernel can't get the processor for it's workque and other crap it thinks it needs to run on YOUR cpu. I think all this throttling crap is more of a "Lets not let userland break our kernel" sort of thing rather than "Lets not let user land break them selves" sort of thing.

I will admit though, for a non SMP box this is probably a good thing as a default setting.

SCHED_FIFO and realtime throttling

Posted Sep 3, 2008 8:40 UTC (Wed) by njs (guest, #40338) [Link]

Presumably you would make _THROTTLED the version that is accessible to non-root users, and leave SCHED_FIFO exclusively for root? (More or less what it says at the end of the article.)

It seems like there are two use cases, traditional real-time systems with more-or-less dedicated systems running custom programs, and the emerging desktop real-time stuff. A process will generally know which sort of process it is? It further seems to me that the former case wants weak emergency-only throttling for all tasks as a development aid, while the latter wants much stronger always-on throttling for unprivileged tasks in particular. (I don't see why unprivileged realtime tasks should have access to "most but not all" of the CPU... the ideal limit would be "you get exactly as much time as the fair staircase scheduler would give you, but since you flipped the realtime bit I will guarantee that you receive it exactly when you ask for it".) But they've made the default limit ~10s, which seems way higher than desired for ordinary desktop use, *and* annoys the hard-core real-time folks... (who aren't annoyed that they'll run uniformly 5% slower, they're scared that the 5% might come in the form of being abruptly descheduled just before a deadline. But it's still hard to imagine a task actually running 10s straight without sleeping, which is why the discussion is all in terms of API guarantees and abstract junk like that.)

Of course, in practice what will probably happen is that we won't end up with anyone's idea of the Platonic real-time API, kernels for both sorts of systems will end up tweaked away from the default anyway, desktop systems will use more elaborate schemes with different users segregated into different control groups with different limits, etc., and things will work out.


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