0

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.

Improve this question

1 Answer 1

Reset to default
1

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

Improve this answer
2
  • 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
    Commented Sep 28, 2017 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
    Commented Sep 28, 2017 at 22:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .