Is it possible to "hang" a Linux box with a SCHED_FIFO process?

Question

I want to have a real-time process take over my computer. :)

I've been playing a bit with this. I created a process which is essentially a while (1) (never blocks nor yields the processor) and used schedtool to run it with SCHED_FIFO policy (also tried chrt). However, the process was letting other processes run as well.

Then someone told me about sched_rt_runtime_us and sched_rt_period_us. So I set the runtime to -1 in order to make the real-time process take over the processor (and also tried making both values the same), but it didn't work either.

I'm on Linux 2.6.27-16-server, in a virtual machine with just one CPU. What am I doing wrong?

Thanks,

EDIT: I don't want a fork bomb. I just want one process to run forever, without letting other processes run.

Answer 1

There's another protection I didn't know about.

If you have just one processor and want a SCHED_FIFO process like this (one that never blocks nor yields the processor voluntarily) to monopolize it, besides giving it a high priority (not really necessary in most cases, but doesn't hurt) you have to:

1. Set sched_rt_runtime_us to -1 or to the value in sched_rt_period_us
2. If you have group scheduling configured, set /cgroup/cpu.rt_runtime_us to -1 (in case you mount the cgroup filesystem on /cgroup)

Apparently, I had group scheduling configured and wasn't bypassing that last protection.

If you have N processors, and want your N processes to monopolize the processor, you just do the same but launch all of them from your shell (the shell shouldn't get stuck until you launch the last one, since it will have processors to run on). If you want to be really sure each process will go to a different processor, set its CPU affinity accordingly.

Thanks to everyone for the replies.

Answer 2

I'm not sure about schedtool, but if you successfully change the scheduler using sched_setscheduler to SCHED_FIFO, then run a task which does not block, then one core will be entirely allocated to the task. If this is the only core, no SCHED_OTHER tasks will run at all (i.e. anything except a few kernel threads).

I've tried it myself.

So I speculate that either your "non blocking" task was blocking, or your schedtool program failed to change the scheduler (or changed it for the wrong task).