问题
this is from sched_setscheduler(2) - Linux man page:
"Processes scheduled under one of the real-time policies (SCHED_FIFO, SCHED_RR) have a sched_priority value in the range 1 (low) to 99 (high)."
"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)."
I have the following code:
struct sched_param sp;
memset( &sp, 0, sizeof(sp) );
sp.sched_priority = 99;
sched_setscheduler( 0, SCHED_FIFO, &sp );
Now the process should be running under the highest possible priority (99) and should never be preempted.
So, when it starts running the following loop:
while ( 1 ) ;
it should be running forever and no other process should be allowed to run.
In spite of this, when I start such a process, I can use other processes too. Other processes run much slower, but they DO run.
My processor has 2 cores, so I started two copies of the process. Usage of both cores jumped to 97%-100%. Both processes were running their infinite loop.
I could still type commands in a shell and watch their output. I could use GUI programs as well.
How's that possible since a SCHED_FIFO process with a priority of 99 should never be preempted?
回答1:
If you haven't changed any other policy settings, then you're likely getting throttled. See this informative article on the real-time limits added to the scheduler a few years back.
The gist of it is: Unprivileged users can use SCHED_FIFO and try to soak the CPU, but the RT limits code will force a little bit of SCHED_OTHER in anyway so you don't wedge the system. From the article:
Kernels shipped since 2.6.25 have set the rt_bandwidth value for the default group to be 0.95 out of every 1.0 seconds. In other words, the group scheduler is configured, by default, to reserve 5% of the CPU for non-SCHED_FIFO tasks.
来源：https://stackoverflow.com/questions/20722615/sched-fifo-process-with-priority-of-99-gets-preempted