Do Linux kernel-Level operations (such as IO operations on the filesystem or communications over an ethernet interface) inherit the priority of the thread that triggered them, or do they run at a separate priority while the calling thread yields?

For example, lets say that I create a thread that has a policy of SCHED_FIFO and a priority of 99 (the highest), which does nothing other than sit in a tight loop and send a single byte out a serial port. Let's call this thread SERIAL_THREAD.

Lets say that I create a second thread that has a policy of SCHED_FIFO and a priority of 98, which does nothing other than sit in a tight loop and send the same TCP IP packet. Let's call this thread IP_THREAD.

Let's also assume the system has a single core, and that thread throttling has been disabled so that a thread is able to consume 100% of the system's CPU resources, blocking anything else from happening.

Regularly, given that SERIAL_THREAD has the highest priority in the system, and it never explicitly yields to the lower priority thread, I would expect that IP_THREAD would never be able to send its TCP-IP packets. However, because the thread interacts with an IO device via the kernel, I'm unsure of whether or not IP_THREAD will have any opportunity to run.


The high priority realtime thread can totally block out all other activity in that tight no-yield loop (unless the I/O blocks somehow)

SCHED_FIFO implements a simple first-in, first-out scheduling algorithm without timeslices. A runnable SCHED_FIFO task is always scheduled over any SCHED_NORMAL tasks. When a SCHED_FIFO task becomes runnable, it continues to run until it blocks or explicitly yields the processor; it has no timeslice and can run indefinitely.

Robert Love. Linux Kernel Development (Third Edition). p. 64.

And for a possible next question:

Two or more SCHED_FIFO tasks at the same priority run round-robin, but again only yielding the processor when they explicitly choose to

  • Does the kernel serial I/O logic execute in the same thread (and therefore at the same priority) that requested the serial write? Or is there a context switch where the requesting thread sleeps while the kernel does its own thing? – Echo404 Sep 28 '17 at 21:31
  • 1
    There is no switch to a "kernel does its own thing" context, a process is running in the same context in both user mode and kernel mode. On the other hand, as mentioned in the answer above, there can be a context switch to another process, if the current process blocks on I/O. If you are writing continuously I find it highly likely for this to happen: CPUs are fast compared to serial I/O or even network I/O. – Johan Myréen Sep 28 '17 at 22:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.