Understanding User vs Kernel Space and Modern I/O Models in Linux

User Space and Kernel Space

For each application process there is a kernel space (shared among processes) and a user space (private to the process), both part of the virtual address space. User processes cannot directly access kernel space; they must copy data to kernel space via system calls. The separation prevents user applications from causing conflicts or kernel crashes.

User space : Executes limited commands (Ring 3) and must use kernel‑provided interfaces to access system resources. Kernel space : Executes privileged commands (Ring 0) and can access all system resources. When writing data, the user buffer is copied to a kernel buffer before being written to a device; when reading, data is copied from the device to a kernel buffer and then to the user buffer.

Blocking I/O (Synchronous I/O)

The request blocks until data is returned. The whole operation is blocking. In the first stage, the user process attempts to read data that has not arrived, so the kernel waits and the process is blocked. In the second stage, after the data is copied to the kernel buffer and becomes ready, it is copied to the user buffer, during which the process remains blocked.

Non‑Blocking I/O (Synchronous I/O)

The call returns immediately regardless of data availability; if no data is present, the process receives an error and retries after a delay. In the first stage the read returns an error, the process repeats until data is ready. In the second stage the data is copied to the kernel buffer and then to the user buffer, during which the process is still blocked. Non‑blocking I/O does not improve performance and can cause busy‑waiting, increasing CPU usage.

I/O Multiplexing (Synchronous I/O)

File descriptors (FD) are unsigned integers that represent files, devices, sockets, etc. I/O multiplexing allows a single thread to monitor multiple FDs and be notified when any become readable or writable, avoiding idle waiting and making better use of CPU resources. Implementations include select , poll , and epoll .

select

typedef long int __fd_mask;

typedef struct {
    __fd_mask fds_bits[__FD_SETSIZE / __NFDBITS];
    /* ... */
} fd_set;

int select(int nfds, fd_set *readfds, fd_set *writefds,
           fd_set *exceptfds, struct timeval *timeout);

The select function monitors up to 1024 descriptors (default) using three fd_set collections for read, write, and exception events. The kernel iterates over the sets up to nfds, waits for readiness or timeout, and returns the number of ready descriptors.

poll

#define POLLIN   /* readable */
#define POLLOUT  /* writable */
#define POLLERR  /* error */
#define POLLNVAL /* invalid fd */

struct pollfd {
    int   fd;      /* descriptor to monitor */
    short events;  /* requested events */
    short revents; /* returned events */
};

int poll(struct pollfd *fds, nfds_t nfds, int timeout);

poll

allows a dynamically sized array of pollfd, removing the fixed limit of select. All requested events are stored in the structure, and the kernel fills revents with the actual events.

epoll

struct eventpoll {
    /* ... */
    struct rb_root rbr;   /* red‑black tree of monitored FDs */
    struct list_head rdlist; /* list of ready FDs */
    /* ... */
};

int epoll_create(int size);
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
int epoll_wait(int epfd, struct epoll_event *events,
               int maxevents, int timeout);

epoll

uses a red‑black tree to store monitored FDs, giving essentially unlimited capacity and O(log N) operations. After adding FDs with epoll_ctl, epoll_wait returns only the ready descriptors, avoiding the need to scan all FDs each time. It supports edge‑triggered (ET) and level‑triggered (LT) notification modes.

Signal‑Driven I/O (Synchronous I/O)

The process registers for the SIGIO signal. When the kernel detects that an FD is ready, it sends SIGIO, allowing the user process to continue other work. Upon receiving the signal, the process calls recvfrom to read data from the kernel buffer.

Asynchronous I/O

The application issues an aio_read request and provides a callback. The kernel performs the I/O in the background; the process remains non‑blocking. When the data is ready, the kernel copies it to user space and triggers the callback via a signal, where the application processes the data.

Summary

The article compares various I/O models—blocking, non‑blocking, multiplexed (select/poll/epoll), signal‑driven, and asynchronous—highlighting their mechanisms, performance characteristics, and typical use cases in Linux.