On Linux SCHED_FIFO and SCHED_RR

Question

I'm writing a a very small daemon that must remain responsive even when a system is under severe stress. I'm looking at the differences between SCHED_FIFO and SCHED_RR in regards to scheduling, as well as trying to determine a sensible priority.

Which scheduler would be appropriate for a small but critical monitoring daemon, what priority would be reasonably safe? I'm still coming up a little fuzzy when trying to understand the differences between the two.

My program is allocating under 3k (and uses mlockall()), it writes about 600 bytes to xenbus then sleeps, but its impossible for me to tell how much time (in ms) it will take to actually write the data.. since what is written depends on a configuration file.

Thanks in advance for any suggestions / explanations.

Pig

Answer 1

The infamous pchdtvr program, which captures digital TV signals, uses SCHED_FIFO to make sure that the TV packets are written to disk no matter what. It can capture 4 shows at once while playing Doom on an old computer.

The program is infamous because it was released under GPL and the author tried to revoke the GPL retroactively. This act provoked a minor firestorm. Anyway, you can find a recent version to study at http://frequal.com/pmn/pchdtvr.html.

Ovid

It is really funny to see developers pick a license that they did not understand .. actually sad, but funny. I'm going to go with FIFO, but 'back off' when the program can and should yield and return to normal scheduling, or back to RT when things get rough. I'll see how that goes. – Pig

@tinkertim: The furor on slashdot was unbelievable. yro.slashdot.org/article.pl?no_d2=1&sid=08/01/26/0341210 – Ovid

Archive link – Lobeline

Answer 2

SCHED_FIFO can't be preempted (context switched to another process) unless another process of higher priority shows up in the execution queue.

SCHED_RR can be preempted by a time quantum (delay given to a process to execute).

They are both "real-time" priorities of linux based schedulers.

Stomatitis

Answer 3

I'm not an expert for scheduling schemes, but have a look at

man sched_setscheduler

it details what the difference between the different scheduling algorithms are, and provide links to other scheduling functions. SCHED_FIFO actually sounds pretty dangerous, but is described as the most aggressive scheduling:

A SCHED_FIFO process runs until either it is blocked by an I/O request, it is preempted by a higher priority process, or it calls sched_yield(2).

Beware not to lock up your system. I would personally do some empirical tests to see what priority fits the best and how they behave exactly.

Sitzmark

Thanks for the reply, I looked at the man pages and various documents that turned up in searches. I'm now using SCHED_FIFO with no issues, but wonder about RR. I don't think I can use RR, since I have no way of knowing if I can actually complete an atomic write in one slice. – Pig

I (could) also call sched_yield() once the contents of sysinfo() become agreeable.. i.e. the system is no longer under stress. Maybe I'll stick with FIFO but write logic to go RT only when the system is (or will soon be) stressed, then go back when its calm. – Pig

hm, yeah i think fifo sounds reasonable for that task. – Sitzmark

Answer 4

If all your other tasks use the standard scheduler, it makes no difference; SCHED_FIFO and SCHED_RR only affect the scheduling of these tasks with each other.

So on a normal system it makes no difference. FIFO is easiest to understand, so use that I guess.

If you have several tasks of different priorities, only the higher one will be run if they are all ready to be run (and there is only one CPU core)

Shroyer