Can someone explain the differences between SCHED_OTHER, SCHED_FIFO and SCHED_RR?
Thanks
SCHED_FIFO and SCHED_RR are so called "real-time" policies. They implement the fixed-priority real-time scheduling specified by the POSIX standard. Tasks with these policies preempt every other task, which can thus easily go into starvation (if they don't release the CPU).
The difference between SCHED_FIFO and SCHED_RR is that among tasks with the same priority, SCHED_RR performs a round-robin with a certain timeslice; SCHED_FIFO, instead, needs the task to explicitly yield the processor.
SCHED_OTHER is the common round-robin time-sharing scheduling policy that schedules a task for a certain timeslice depending on the other tasks running in the system.
Update: since Linux 3.14, there is an additional policy called SCHED_DEADLINE. This policy implements the Constant Bandwidth Server (CBS) algorithm on top of Earliest Deadline First queues. Each task under this policy is assigned a deadline, and the earliest-deadline task is executed. The best resource describing this algorithm is Deadline scheduling in the Linux kernel.
Update 2: since Linux 4.13, SCHED_DEADLINE has replaced CBS with the Greedy Reclamation of Unused Bandwidth (GRUB) algorithm.
Here is the differences between SCHED_OTHER, SCHED_FIFO and SCHED_RR based on Linux Manual (http://man7.org/linux/man-pages/man7/sched.7.html)
SCHED_FIFO: First in-first out scheduling
SCHED_FIFO can be used only with static priorities higher than 0, which means that when a SCHED_FIFO threads becomes runnable, it
will always immediately preempt any currently running SCHED_OTHER,
SCHED_BATCH, or SCHED_IDLE thread. SCHED_FIFO is a simple scheduling
algorithm without time slicing.
SCHED_RR: Round-robin scheduling
SCHED_RR is a simple enhancement of SCHED_FIFO. Everything described above for SCHED_FIFO also applies to SCHED_RR, except that
each thread is allowed to run only for a maximum time quantum. If a
SCHED_RR thread has been running for a time period equal to or longer
than the time quantum, it will be put at the end of the list for its
priority.
SCHED_OTHER: Default Linux time-sharing scheduling
SCHED_OTHER can be used at only static priority 0 (i.e., threads under real-time policies always have priority over SCHED_OTHER
processes. SCHED_OTHER is the standard Linux time-sharing scheduler
that is intended for all threads that do not require the special
real-time mechanisms.
Related
Why, in Linux, the sched_fifo and the sched_rr are called real-time schedulers, while sched_other is called non real-time scheduler ?
The term "real-time" when it comes to schedulers is used to denote if that scheduler can mathematically guarantee that within certain parameters all the periodic tasks within the system will meet their deadlines. This is important in things like closed loop control.
The problem with the Linux kernel is that even if you are using a real-time scheduler you do not have the guarantee that you will meet deadlines because of things like spin locks in the kernel itself. If you want true hard real-time you have to not only use a real-time scheduler but have to use the real-time patches as of this writing. In the future it is intended by some in the community that those patches be put into the mainline kernel.
The scheduler is the kernel component that decides which runnable thread will be executed by the CPU next. Each thread has an associated scheduling policy and a static scheduling priority, sched_priority. The scheduler makes its decisions based on knowledge of the scheduling policy and static priority of all threads on the system.
For threads scheduled under one of the normal scheduling policies (SCHED_OTHER, SCHED_IDLE, SCHED_BATCH), sched_priority is not used in scheduling decisions (it must be specified as 0).
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). (As the numbers imply, real-time threads always have higher priority than normal threads.)
Do two SCHED_FIFO tasks with equal priority get processing time within each period in Linux, granted neither of the tasks finish before the period ends?
Linux documentation says SCHED_FIFO processes can get preempted only by processes with higher priority, but my understanding is that CFS operates on a higher layer, and assigns timeslots to each of the two tasks within each period.
Linux documentation says SCHED_FIFO processes can get preempted only by processes with higher priority
This is correct, in addition to this, they can also be preempted if you set RLIMIT_RTTIME (getrlimit(2)) and that limit is reached.
The only other reasons why another SCHED_FIFO process (with the same priority) can be scheduled is if the first sleeps or if it voluntary yields (voluntary preemption).
CFS has nothing to do with SCHED_FIFO, it only takes care of SCHED_NORMAL, SCHED_BATCH and SCHED_IDLE.
im having some hard time understanding the sched_priority role in the setscheduler func.
Im using linux 2.4.X, and the documentation says :
Valid priorities for SCHED_OTHER is 0, Valid priorities for SCHED_RR\FIFO are 1...MAX_USER_RT_PRIO-1
But, I remember that priorities for rt procsses are 0-99, and for SCHED_OTHER 100-139, so... what did I miss ? what sched_priority in struct sched_param refers to?
SCHED_OTHER is the default scheduling policy with round robin. This is has no choice of priority.
SCHED_FIFO and SCHED_RR are real time scheduling policies for which the priority range from 1 to 99.
SCHED_OTHER, SCHED_BATCH and SCHED_IDLE are normal scheduling policies.
From Linux 3.14 onwards, you will find SCHED_DEADLINE that in which the task with earliest deadline is executed first.
You can use the sched_priority to set the thread priority. sched_priority is a member of the structure struct sched_param.
Try out chrt -m to check the min/max valid priorities that can be configured/set. chrt can be used to set or retrieve scheduling attributes of processes.
You are confusing the user space interface with the internal kernel implementation.
sched_priority is just the requested fixed real time priority.
A task scheduled under the SCHED_OTHER policy also has a nice level.
The scale you remember is the kernel internal representation of the relative priority of a task, aggregating real time tasks and SCHED_OTHER tasks with their respective nice levels.
I am testing my multithreaded application in Linux RT multicore machine.
However during testing, we are observing that scheduling (created with SCHED_FIFO scheduling policy ) in Linux RT is not happening according to the SCHED_FIFO policy.
We could see in multiple places that the higher priority thread execution is getting preempted by a lower priority thread.
Based on some research we did on the internet, we found that the following kernel parameters need to be changed from
/proc/sys/kernel/sched_rt_period_us containing 1000000
/proc/sys/kernel/sched_rt_runtime_us containing 950000
to
/proc/sys/kernel/sched_rt_period_us containing 1000000
/proc/sys/kernel/sched_rt_runtime_us containing 1000000
or
/proc/sys/kernel/sched_rt_period_us containing -1
/proc/sys/kernel/sched_rt_runtime_us containing -1
We tried doing both but still we are facing the problem sometimes. We are facing the issue even when higher priority thread is not suspended by any system call.
It would be great if you could let us know if you are aware of such problems in Linux RT scheduling and/or have any solutions to make the Linux RT scheduling deterministic based on priority.
There are no printfs or any system calls in the higher priority thread but still the higher priority thread is getting preempted by the lower priority thread.
Also I have made sure all the threads in the process are running on a single core using taskset command.
There could be two reasons:
CPU throttling: the scheduler is designed to reserve some CPU time to non-RT tasks; you have already disabled it by acting on the /proc/sys/kernel/ entries
blocking: your high-priority task is blocking either
on some synchronization mechanism (e.g., mutex, semaphore) or
on some blocking call (e.g., malloc, printf, read, write, etc.)
SCHED_FIFO and SCHED_RR are both meant for real-time uses. I am aware that SCHED_RR can be preempted by time slicing. But say if I have one thread set to SCHED_FIFO, and another set to SCHED_RR, if both threads are ready to run, are they scheduled purely by priority? What if they have same priority?
Conceptually, there is a list of runnable processes associated with each static priority level. These lists can contain both SCHED_FIFO and SCHED_RR processes - the two scheduling policies share the same set of static priorities.
When selecting a process to run, the scheduler takes the process at the head of the non-empty list with the highest static priority, regardless of the scheduling policy of that process.
The scheduling policies affect how the processes move within those lists. For SCHED_FIFO, once a process reaches the head of the list for a given priority it will stay there until it blocks or yields. For SCHED_RR, a runnable process that has exceeded its maximum time quantum will be moved to the end of the list for its static priority.