Before diving into individual subsystems — schedulers, memory managers, filesystems, or drivers — we need a clear mental map of how the Linux kernel is structured as a whole.

Without this map, kernel internals feel like a collection of unrelated mechanisms.

With it, the kernel becomes a coherent system where every component has a defined role and set of responsibilities.

This chapter builds that map.

At a high level, the Linux kernel can be understood as a layered architecture, even though internally it is not strictly layered in a classical sense.

Conceptually, the kernel sits between:

• hardware (CPU, memory, devices)

• user space (applications, services, containers)

Its job is to translate high-level requests into low-level operations while enforcing safety, isolation, and fairness.

While the kernel is one binary, it is divided into several major domains:

This domain controls execution.

It is responsible for:

• creating and destroying processes

• scheduling CPU time

• handling context switches

• managing threads and task states

Every running program exists because the kernel tracks it as a task structure and schedules it onto a CPU.

Nothing executes “on its own”.

This domain controls address space and memory lifetime.

Responsibilities include:

• virtual memory abstraction

• page allocation and reclamation

• memory isolation between processes

• caching and buffering

• handling page faults

From the application’s point of view, memory looks infinite and contiguous.

In reality, the kernel is constantly mapping, unmapping, and reclaiming physical pages.

This domain controls persistent and streamed data.

It handles:

• filesystem abstractions (VFS)

• block devices

• page cache

• read/write paths

• asynchronous I/O

Whether data comes from disk, network, or a virtual filesystem, it flows through unified kernel interfaces.

This is why vastly different storage technologies can be accessed with the same system calls.

Drivers are the kernel’s hardware translators.

They:

• expose hardware functionality

• handle interrupts

• manage DMA and registers

• present devices as files, sockets, or interfaces

Drivers are the reason Linux can run on everything from routers to supercomputers.

Networking is a first-class kernel subsystem.

It includes:

• protocol implementations (TCP/IP, UDP, ICMP)

• packet routing and filtering

• socket abstractions

• traffic shaping and isolation

Containers, Kubernetes, and modern cloud networking are all built on top of this stack.

Security is not a separate add-on — it is deeply embedded.

The kernel enforces:

• user and group permissions

• capabilities

• namespaces

• cgroups

• LSM frameworks (SELinux, AppArmor)

Every access decision flows through these checks.

Kernel subsystems do not operate in isolation.

For example:

• A process reads a file → process management + filesystem + memory management

• A container starts → namespaces + cgroups + scheduler + filesystem

• A network packet arrives → driver + networking stack + process wakeups

The kernel is a dense interaction graph, not a linear pipeline.

Understanding this interaction is far more important than memorizing individual functions.

Linux is often described as a monolithic kernel, and that is technically correct.

However, it is also highly modular:

• loadable kernel modules

• pluggable schedulers

• multiple filesystem implementations

• interchangeable security frameworks

This combination gives Linux both performance and flexibility.

When something goes wrong, symptoms rarely point directly to the cause.

High load may be:

• CPU pressure

• memory reclaim

• I/O wait

• scheduler contention

Without architectural context, debugging becomes guesswork.

With it, you can reason about which domain is likely responsible — and why.

As we continue through the book, keep this simple model in mind:

Processes request → subsystems cooperate → hardware executes

Every optimization, limitation, and bottleneck fits somewhere into this flow.

Now that we have a high-level map, we can start zooming in.

Next sections will explore:

• how the kernel represents processes internally

• how scheduling decisions are made

• how CPU time is actually distributed

This is where architecture turns into mechanics.