I/O bound vs CPU bound depend on kernel?

Viewed 107

I saw this question online preparing for a job interview:

Given a non-preemptive kernel which type of process will get affected more in terms of performance and why?

  1. I/O bound

  2. CPU bound


I know that a CPU-bound process gets long quanta but with low priority, wWhereas an I/O-bound process gets short quanta with high priority.

At first I though I/O bound will get affected more since it must wait for reading from disk to finish (and not just to ask the OS to wake it up when something is ready). But I think this is wrong since even in non-preemptive kernel a process can decide by itself to finish its job and let another work.

I am looking for detailed answer to deeply understand what I am missing here.

1 Answers

I think that is a trick question. The difference between a preemptive and non-preemptive kernel is in the way that thread that are in kernel mode are scheduled. (See What is the difference between Non-preemptive, Preemptive and Selective Preemptive Kernel?)

  • This makes no difference to a CPU-bound thread, since such a thread will be executing in user mode the whole time.

  • It also makes little difference to a (normal) I/O bound thread. While the thread will be in kernel mode while blocked on I/O, the kernel thread will be de-scheduled when waiting for a physical I/O event to occur.

  • However, it does make a difference for real-time threads doing I/O. If a real-time (high priority) thread is waiting on an I/O event and the event happens, you want the current kernel thread (if any) to be preempted so that the high priority kernel thread can take over. A preemptive kernel allows that. A non-preemptive thread doesn't, and the high-priority thread is held up until the low-priority one finishes what it is currently doing.

  • It might also make a difference to how different kinds of I/O are (effectively) prioritized; e.g. the "soft real-time" characteristics of I/O.

(Apparently ... Linux kernels only allow one kernel thread to be active at a time for thread-safety reasons.)

In your question, you are speculating about user-mode preemption. AFAIK, that is a orthogonal to kernel-mode preemption, and preemptive / non-preemptive kernels.

Related