Real time processes

mircan · 12-07-2009, 06:48 AM

Hi,

I've got the following problem:
1. I start two bash windows
2. In one of them I start a script test1:

Code:

#!/bin/sh

counter=0;
while true; do
	counter=`expr $counter + 1`;
	sleep 0.2;
	echo "$counter";
done

This script puts a natural number 5 times a second.
3. Then in the second bash window I type (as root):

Code:

chrt -rr 99 ./test2

The script test2 looks as follows:

Code:

#!/bin/sh

(sleep 15; kill -9 $$) &

while true; do
	true;
done

During the following 15 seconds test2 is the process with the highest real-time priority. As far as I know the script doesn't perform any system calls so it shouldn't be suspended even for a minimal timeslice. My question is: why the process test1 manages to put a few numbers on the screen before test2 stops. I thought that test2 would exclusivly own the processor for 15 seconds. Am I wrong?

estabroo · 12-07-2009, 08:47 AM

sleep and kill are both system calls

mircan · 12-07-2009, 01:26 PM

Quote:

sleep and kill are both system calls

Indeed, but i meant there are no system calls after calling sleep and before kill, during the 15-second execution of the loop. The script test1 puts some numbers on the screen during those 15 seconds.

estabroo · 12-07-2009, 04:33 PM

ah, I see what you mean, well script2 is asleep for those 15 seconds, so its not taking any cpu time regardless of its priority

mircan · 12-07-2009, 04:52 PM

Quote:

Originally Posted by estabroo

ah, I see what you mean, well script2 is asleep for those 15 seconds, so its not taking any cpu time regardless of its priority

Maybe I'm not writing clearly.
The sleep and kill commands are started in the background, only to stop the script after 15 seconds. During this 15 seconds the script is executing an endless loop, so it really is taking cpu time. As test2 is a real-time process, I think the scheduler shouldn't preempt it, but in fact test1 manages to put some numbers on the screen (but not 5 times a second as if test2 was not running). And my question is how this happens. I thought that test2 shouldn't be preempted during this 15 seconds.

chrism01 · 12-07-2009, 11:02 PM

sleep doesn't run in the cpu, or nobody would ever get any work done. It sets an interrupt, so the kernel/cpu can deal with other stuff while its waiting.

estabroo · 12-08-2009, 12:55 PM

mircan, I see what you mean now, I guess the question is can userspace have hard realtime processes, I'd guess at best it gets a minimum latency between time slices but isn't guaranteed all the time slices.

mircan · 12-08-2009, 02:46 PM

Quote:

Originally Posted by estabroo

mircan, I see what you mean now, I guess the question is can userspace have hard realtime processes, I'd guess at best it gets a minimum latency between time slices but isn't guaranteed all the time slices.

Yeah, that is my question. Perhaps you're right. Thanks for the answer.

mircan · 02-12-2010, 07:29 AM

I've found out what is the problem. I'm writing here in case anyone is interested. As I experienced my problem occurs only in kernels with Completely Fair Scheduler. The solution is simple. In CFS there are two new options sched_rt_runtime_us and sched_rt_period_us. The first is the period of time after which all real time process will be preempted and the second is the period after which any of real time processes can run again. By default they are 0.95 s and 1 s. And this is the reason of my problem. The options values can be dynamically changed.

Code:

sysctl -w kernel/sched_rt_runtime_us=-1

This makes preempting of a real time process in order to run a normal process not possible.