choosing priority of processes in linux 2.6

Hello,

I am working on an embedded Linux system (the latest kernel version

2.6.23) with 3 RT low-latency processes, and 5 processes with normal priority. We do not use interrupts, but periodically poll for data in a RT low-latency process to check when the data was written. These low-latency processes should not run for longer then 5 ms, and the CPU load should be about 50%. Low latency processes with run with SCHED_FIFO, and normal processes with SCHED_OTHER setup.

Can someone recommend me where to read about choosing the priority of a process? I have read about process priority in man pages for sched_setsheduler (3), but it does not say anything whether I can somehow make the kernel non-responsive with choosing too high priorities. Can anything go wrong if the chosen priorities are too high?

Thanks in advance.

Reply to
anon
Loading thread data ...

There is nothing like "too high". If one of your RT processes consumes all computing power *and* has the highest priority your system seems dead. This can also happen, if you have only one RT process with priority 1 and all other processes are using SCHED_OTHER!

JB

Reply to
Juergen Beisert

RT processes in Linux are just "more real time than average" but no "hard real time".

You do use interrupts. AFAIK, the Kernel can't but use interrupts for timing. If "periodically poll" means "run all the time", no lower priority process will run at all, thus the process usually sits waiting for a system timer condition (hence an interrupt).

"should" is OK (= soft real time) but "need to" (= hard real time) can't be done.

priorities are just mutually relative. If there is nothing else to do the lowest priority runs full speed. If any RT priority process is active, all lower priority RT (and thus all non-RT processes) will not be scheduled at all. Only processes with the same RT priority will be grated time-slices.

-Michael

Reply to
Michael Schnell

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.