What the kernel does

The kernel is the first software that runs when your server boots, directly after the firmware. Everything that happens afterward—every network connection, every file on disk, every running process—passes through that single layer. Without a kernel, your machine is a collection of separate components that don't talk to each other.

This article explains what the kernel does on Linux systems and why those choices matter. You don't need special access, just a Linux system and curiosity about what lies beneath your commands.

Interrupts: the kernel as a receptionist

When you press a key on your keyboard, the keyboard controller sends a signal to the CPU. That signal is an interrupt—an interruption that demands the processor's attention. The kernel catches this signal and ensures that the right part of the system is informed.

Without proper interrupt handling, your system wouldn't respond to user input, network traffic, or disk activity. The kernel processes these signals efficiently, without interrupting processes in a way that slows down the system or makes it unstable.

On Linux, you can see interrupts live:

watch -n1 cat /proc/interrupts

Each line shows an interrupt line, the number of times it has been triggered per CPU core, and which device is behind it. You'll see network cards, disk controllers, and timers—all handled through the same kernel mechanism.

Memory management: who gets what

Working memory is limited and must be carefully allocated. The kernel decides which process gets how much memory and when. This isn't an administrative formality: if processes had arbitrary access to each other's memory, any program could read or overwrite any other program.

When you start an application, it requests memory from the operating system. The kernel fulfills that request but keeps careful track of what is being used. If memory runs out, the kernel determines which memory can be temporarily freed or swapped out to disk.

The kernel also manages virtual memory. This system only works if the processor has a Memory Management Unit (MMU)—and all modern x86 and ARM processors do. Virtual memory gives each process its own, isolated memory space, as if it were the only application running.

A process thinks it has a large block of memory, while in reality it is split across physical RAM and extended to disk via swap. The kernel translates virtual addresses to physical ones, so processes never have to work directly with physical locations. This not only increases efficiency but also security.

A direct consequence of virtual memory: if a program crashes or is hacked, it normally can't damage other programs. It is confined to its own virtual memory space, and the kernel strictly separates those spaces. This principle underpins modern multitasking: multiple programs run simultaneously without disturbing each other.

Processes and scheduling

A process is an active instance of a program. The kernel starts processes, stops them, and ensures they get access to the processor in an organized manner. This is called scheduling.

There are almost always more active processes than there are cores in the processor. The kernel must therefore decide which process gets to use the processor at which moment. The scheduler in the Linux kernel assigns priorities based on urgency, user permissions, and the type of task. A web browser you're actively using gets priority over a background task like a system update.

You can watch the scheduler at work:

ps aux --sort=-%cpu | head -10

This shows the ten processes currently consuming the most CPU time. Behind that order is your kernel's scheduler.

System calls: the bridge

Software communicates with the kernel through system calls, such as read() and write(). When a program wants to read or write a file, it calls these functions. The kernel catches the call, checks whether the program has the right permissions, and performs the actual read or write action on the disk.

This layer forms the bridge between userspace and kernelspace—a strict separation that ensures stability and security. A program cannot perform any hardware action without the kernel checking it.

You can track system calls live with strace:

strace -c ls /tmp

This runs ls and then shows a summary of all system calls the kernel has handled. You'll see read, write, open, close, mmap, and dozens of others—all controlled by the kernel.

The kernel in numbers

Development is done by a worldwide network of developers, but Torvalds remains the leading figure in the process. This isn't a historical footnote: it determines how the kernel is managed and how decisions are made.

The kernel contains drivers for hardware, network protocols, file systems, and support for countless processors and devices. Modularity makes it possible to add or remove features without restarting the entire system. That's why Linux runs on smartphones, routers, supercomputers, and cloud servers.

What the kernel costs you

The kernel solves a lot, but not for free. Every system call means a context switch: the processor switches from userspace to kernelspace and back again. That costs CPU cycles. The scheduler and memory management also consume processor capacity. On a modern server, that is negligible — usually less than one percent of CPU time. But on embedded systems with a slow processor, it counts.

The kernel is also a piece of software you have to maintain. Security updates come out regularly and must be installed. A kernel update requires a reboot, unless you work with live patching like kpatch or kexec. That is extra complexity you only want if a reboot is unacceptable.

The biggest cost, however, is not technical. The kernel is flexible, but that flexibility means you have to make choices. A kernel compiled for everything is large and slow. A kernel tailored to your hardware is faster and more secure, but requires that you know what your system needs. Distribution kernels like those from Debian or Ubuntu are a good middle ground: they run on almost anything, but contain many modules you do not use.

Self-hosting sounds wonderful, until something falls over on Sunday evening at half past eleven. Then you are not a customer waiting on the helpdesk. Then you are the helpdesk.

Verification

Check which kernel you are running:

uname -r

That shows your kernel version, for example 6.1.0-18-amd64 on Debian 12. Compare it with the version your distribution supports. A kernel that is too old misses security patches and support for new hardware.

Look at which kernel modules are loaded:

lsmod

This shows loaded modules, their size, and which other modules they use. If your network card does not work, the chance is large that the right module is missing.

Common mistakes

Postponing kernel updates. A kernel contains security patches that are directly relevant for a server that is on the internet. Do not postpone updates because a reboot is inconvenient. Plan a reboot, or use live patching if that really cannot happen.

Loading too many modules. Every loaded module is a potential attack surface. Distribution kernels load many modules you do not need. For a server that only serves web traffic, modules for bluetooth and consumer audio are superfluous. Remove them via modprobe -r or put them on the blacklist.

Confusing the kernel with the distribution. The kernel is one part of your operating system. The tools you use — systemd, bash, the package manager — run in userspace and are not the kernel. If you confuse them, you solve problems at the wrong layer.

The kernel is the invisible director of your system. It coordinates all parts, protects the integrity of the hardware, and ensures isolated and secure execution of programs. Without the kernel, your server remains a collection of unconnected components. With the kernel, it becomes an integrated, working whole — and that whole is exactly as good as the choices you make in the layer above it.