Understanding User vs Kernel Space, Process Switching, and Linux I/O Models

User Space and Kernel Space

The operating‑system kernel runs independently of regular applications and has full access to protected memory and hardware. To keep user processes from directly manipulating the kernel, the virtual address space is divided. On a typical 32‑bit Linux system the upper 1 GB (0xC0000000‑0xFFFFFFFF) is reserved for kernel space, while the lower 3 GB (0x00000000‑0xBFFFFFFF) is available to user processes.

Process Switching

In a multitasking environment a context switch from one process to another follows these steps:

Save the processor context (program counter and registers).

Update the Process Control Block (PCB) of the outgoing process.

Move the PCB to the appropriate queue (ready, blocked, etc.).

Select the next process to run and update its PCB.

Update memory‑management data structures.

Restore the processor context for the incoming process.

I/O Models

1. Synchronous I/O

Blocking I/O

Non‑blocking I/O

Multiplexing I/O (select/poll/epoll)

Signal‑driven I/O

2. Asynchronous I/O

A read operation first copies data from the device into a kernel buffer, then copies it from the kernel buffer to the user address space. The operation consists of two phases:

Waiting for the data to become ready.

Copying the data from the kernel buffer to the process.

3. Blocking I/O

The process blocks until the kernel‑to‑user copy completes.

Advantage: immediate data return with no latency.

Disadvantage: the process wastes CPU time while waiting.

4. Synchronous Non‑blocking I/O

The application repeatedly invokes the I/O function; while the kernel copies data, the process is blocked.

Advantage: the process can perform other work between polls.

Disadvantage: increased response latency because polling occurs at intervals, reducing overall throughput.

5. I/O Multiplexing (select/poll/epoll)

5.1 Select Model

User space creates an fd set and passes it to select().

The kernel copies the set, scans for ready descriptors, sleeps if none are ready, then copies back the ready set.

User space iterates the returned set and performs I/O on ready descriptors.

Drawbacks: each poll traverses the entire fd set (inefficient), limited to 1024 descriptors, and incurs user‑kernel copying overhead.

5.2 Poll Model

User space builds a custom fd array and copies it to the kernel, where it is stored as a linked list.

The kernel scans the list, marks ready descriptors, and copies the count of ready fds back to user space.

User space processes the ready descriptors.

Improves the 1024‑fd limit but can suffer performance degradation with many events due to linked‑list traversal.

5.3 Epoll Model

eventpoll

maintains all monitored fds in a red‑black tree. epoll_ctl adds or removes fds from the tree and binds a callback. epoll_wait blocks until at least one fd becomes ready; ready fds are moved to a linked list and copied to a user‑space events array.

Supports edge‑triggered (ET) and level‑triggered (LT) modes. LT notifies the application each time an event occurs; ET requires the application to handle the event immediately, offering higher efficiency for complex workloads.

6. Asynchronous I/O (Linux 2.6.22+)

Data copying occurs without blocking the calling process.

Advantage: no process blocking.

Disadvantage: application must implement flow‑control or rate‑limiting.

7. Signal‑driven I/O

The process opens a file and registers a signal handler (e.g., for SIGIO). The process does not block; when the kernel detects that the file descriptor is ready, it sends the signal, causing the handler to execute and notify the application.

Comparison of I/O Models

Blocking vs Non‑blocking: Blocking I/O stalls the process until the operation finishes; non‑blocking I/O returns immediately if data is not ready.

Synchronous vs Asynchronous: Synchronous I/O (including blocking, non‑blocking, multiplexing, signal‑driven) blocks during the kernel‑to‑user copy phase; asynchronous I/O avoids this block.