Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

The question is as the title says, are there any downsides of running processes with real-time priority (chrt -f 99)?

My hypothesis is that this combined with an affinity will ensure that any pre-emption of my process is minimal and therefore any jitter (specifically network latency) will be minimised - this will not help with overall latency, but at this moment I'm more concerned with jitter.

(Kernel: 2.6.16/3.0)

share|improve this question
This looks helpful for you: How to reduce jitter for Java? – ire_and_curses Sep 18 '12 at 14:15
@ire_and_curses, currently the process runs on it's own isolated core (at least the main processing thread), however the interrupts aren't scheduled on that same core (can't do this as there are several similar processes relying on the same network interface), this is more of a last effort.The APIC frequency is interesting, I've not encountered this before. – Nim Sep 18 '12 at 14:20

The most immediate downside of running a realtime process is that the process can easily starve out every other process on the system. The result from your point of view will be that the computer is completely unresponsive to keyboard, mouse, and probably network, for as long as the realtime process is using the CPU. This can happen if something goes wrong and the process goes into an infinite loop, or even temporarily if the process starts a long-running calculation without waiting for input periodically. (So, for example, don't run SETI@home with realtime priority.)

A lone single-threaded process on a multi-core CPU is less likely to cause this problem since there are other cores that the lower-priority process can use. But if that process creates any child processes, they will inherit the same realtime priority, so things can get out of control if you aren't careful.

The sched_setscheduler(2) man page has good advice:

Since a nonblocking infinite loop in a process scheduled under SCHED_FIFO or SCHED_RR will block all processes with lower priority forever, a software developer should always keep available on the console a shell scheduled under a higher static priority than the tested application. This will allow an emergency kill of tested real-time applications that do not block or terminate as expected. See also the description of the RLIMIT_RTTIME resource limit in getrlimit(2).

That should be a shell on the console -- not under an Xterm, unless you want to give all of X realtime priority as well.

share|improve this answer
Yes - this is the main problem that I appear to encounter. Short of reading through the kernel code to determine all the processes that need to have a higher priority, the only option is to starve all others aside from my process and then move anything that requires any form of io to other cores... hmmm... – Nim Oct 18 '12 at 10:28

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.