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

I realize sched_rt_period_us and sched_rt_runtime_us are meant to prevent freezing the system in case of runaway RT task. I wonder though, if it's possible to use a small value of sched_rt_period_us to assure the task is running smoothly.

I have a simple job that requires no more than a millisecond or so of CPU time per call - say, driving a stepper motor over GPIO pins. I'd like to achieve no less than 100 cycles per second though, sustained. That's no more than 10% of the CPU time - discounting pre-emption and scheduler overhead.

I've read "very small values in sched_rt_period_us can result in an unstable system"1 but it wasn't said what order of magnitude counts for "a very small value". Can I reliably count on no more than 0.01s delay between calls to my program if I set sched_rt_period_us to 10000 and return control (sched_yield()) in timely manner?

The underlying CPU would likely be 850MHz ARM with a number of other tasks than said control, but none of them realtime or even required to "feel responsive", still, unlike with defaults of sched_rt_period_us and sched_rt_runtime_us (95% out of 1s) I can't allow the RT task to sleep whole 0.05s at a time.

share|improve this question

There isn't a whole lot to find related to this question but I did find this thread. It's a bit dated from 2009, and it's regarding the 2.6.X Linux Kernel but seemed apt.

The title of this thread, Subject: question on sched-rt group allocation cap: sched_rt_runtime_us - msg#01766.


I have written a small test program that:

(a) forks two threads, one SCHED_FIFO and one SCHED_OTHER (this thread is reniced to -20) and ties both of them to a specific core.

(b) runs both the threads in a tight loop (same number of iterations for both threads) until the SCHED_FIFO thread terminates.

(c) calculates the number of completed iterations of the regular SCHED_OTHER thread against the fixed number of iterations of the SCHED_FIFO thread. It then calculates a percentage based on that.

I am running the above workload against varying sched_rt_runtime_us values (200 ms to 700 ms) keeping the sched_rt_period_us constant at 1000 ms. I have also experimented a little bit by decreasing the value of sched_rt_period_us (thus increasing the sched granularity) with no apparent change in behavior.

My observations are listed in tabular form:

Ratio of # of completed iterations of reg thread / sched_rt_runtime_us / # of iterations of RT thread (in %) sched_rt_runtime_us

  • 0.2 100 % (regular thread completed all its iterations).
  • 0.3 73 %
  • 0.4 45 %
  • 0.5 17 %
  • 0.6 0 % (SCHED_OTHER thread completely throttled. Never ran)
  • 0.7 0 %
share|improve this answer
Unfortunately this is for sched_rt_period_us = 1s and heavy workload - system overhead almost insignificant to task work time. My case is pretty much opposite, very short period, light workload, extremely frequent task switching = big system overhead. – SF. Nov 30 '13 at 16:15
@SF - yeah that's what I was afraid of. This thread was about the only thing I could dig up related to this. I think you might need to do as this author and create a little testing app scenario similar to theirs and sweep the range of values to see what happens. – slm Nov 30 '13 at 16:22

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.