What an operating system does

Why it matters

A Go service that slows under load, a Postgres instance that stalls every few minutes, a pod killed with exit code 137, a process that cannot open another file: none is explained by the application code alone. Each is the operating system sharing CPU, memory, disk and network among programs that together want more than the machine has. Engineers who can see that layer read top, vmstat and /proc as fluently as a stack trace, and interviews probe it early.

The idea

An operating system sits between the hardware and every program and does two jobs at once. It is a resource manager: it decides which thread gets a core and for how long, how physical memory is divided, and in which order disk requests are served. And it is an abstraction layer: it hides a messy collection of chips and cables behind a few clean objects programs can reason about.

Resources and their abstractions

A process believes it owns a CPU and a private memory starting at address zero, sees a file as a byte array and a socket as a pipe to another machine. The kernel keeps those beliefs true by multiplexing real hardware behind them.

Kernel space and user space

The kernel is the part of the OS that runs with full hardware privilege. It owns the page tables, device registers, scheduler and file system code, and only it may touch them. Everything else, the shell, daemons, databases and your service, runs in user space, each in its own address space with no direct path to hardware. The User mode, kernel mode and protection lesson explains how the CPU enforces that line; the System calls lesson covers crossing it on purpose.

Libraries versus the kernel

Much of what feels like "the OS" is not kernel code. malloc manages a heap inside the process and asks the kernel for pages, through mmap or brk, only when the heap runs out. printf formats in user space and calls write once per buffer flush. The Go runtime multiplexes thousands of goroutines onto a few kernel threads; the JVM does the same for virtual threads. The rule: the kernel is called when a program needs something only privileged code can do; everything else is a library, and the side a call lands on is where its cost comes from.

The services

1. 1

   Scheduling

   Which runnable thread gets each core and for how long: EEVDF on Linux, with slices of a few milliseconds. It is why a batch job can starve a latency-sensitive service on the same host.
2. 2

   Isolation

   Each process gets its own address space, so one crash is contained; files, sockets and devices carry owners and permission bits checked on every open.
3. 3

   I/O

   Drivers talk to devices, the page cache keeps hot file data in RAM, and a thread sleeps until its packet or block arrives.
4. 4

   Naming

   Paths, PIDs, ports and device names are the kernel's name tables: a path resolves to an inode, port 5432 to a listening socket. A container has its own copies of these tables.
5. 5

   Accounting

   CPU time, memory and open files are counted per process and per cgroup, and caps enforced. Exit code 137 is the memory limit being hit and the OOM killer sending SIGKILL.

Why every performance question ends here

A request spends its life being scheduled onto a core, faulting in pages, waiting for a disk or a network card, and crossing the user/kernel boundary. When latency is bad, "where did the time go" ends in one of four places: waiting for CPU (the r column of vmstat 1), for memory (swap in si and so), for I/O (iostat await) or crossing boundaries too often (high sy time, cs switches). The numbers matter: a system call costs hundreds of nanoseconds, a context switch a few microseconds, a page fault from an SSD about 100 microseconds, from a spinning disk about 10 milliseconds.

Trade-offs

Abstractions are not free. Every layer that hides hardware adds a copy, a check or a queue: the page cache duplicates what a database caches, the socket API copies every byte, and the scheduler's fairness is paid for in switches. Programs that need the last ten percent, databases using direct I/O or DPDK packet processors, bypass parts of the OS and take on its duties. The illusions also fail at the edges: overcommit means a process can be killed for touching a page it was promised, and a write that returned has not reached the disk until fsync does.

In an interview

Frame the OS as the layer that turns one machine into many, and yourself as someone who notices when the illusion leaks. "The kernel multiplexes hardware among processes and gives each the picture of a private machine; latency problems are that picture breaking, so I start with CPU, memory, I/O and boundary crossings." Or: "Exit code 137 told me the memory cgroup had killed the container, so the fix was the heap limit, not the error handling."