OS Resource Management: CPU Scheduling Explained

Updated on Sep 20, 2026

10 min read

Every running program competes for finite processor time, memory, and input/output capacity. OS resource management is the set of kernel mechanisms that decide which work runs, how long it runs, and what happens when demand exceeds capacity. This guide focuses on CPU scheduling while connecting it to memory pressure, I/O waits, priorities, and containers. It is useful for developers, system administrators, and anyone diagnosing latency or poor application throughput.

What Is OS Resource Management?

An operating system sits between applications and hardware. It turns physical resources into controlled, shareable abstractions: processes and threads for CPU execution, virtual address spaces for memory, and file or device operations for I/O. The kernel tracks demand and applies policies so one workload does not normally monopolize the machine.

The most visible part is the scheduler. A scheduler selects a runnable task and assigns it to an available CPU. When the task blocks for disk or network I/O, finishes, or uses its scheduling time slice, the kernel can select another task. On a multicore system, it also balances work across CPUs while trying to preserve cache locality.

Linux is a project and a kernel, not a single scheduling policy. Its scheduler is implemented in the kernel and evolves with workload requirements. The Linux kernel scheduler documentation describes the scheduler’s design and tunable interfaces, while the Linux kernel project homepage is the authoritative starting point for source, releases, and documentation.

Why Scheduling Exists

Without scheduling, a process that enters an endless loop could prevent every other program from making progress. A cooperative system can ask applications to yield, but a faulty or malicious program can simply refuse. Modern general-purpose operating systems therefore use preemptive scheduling: the kernel can interrupt a running task and give the CPU to another task.

Scheduling solves several competing goals:

Responsiveness: interactive work should receive CPU time quickly.
Fairness: runnable users and processes should receive a reasonable share.
Throughput: the system should complete as much useful work as possible.
Predictability: latency-sensitive tasks need bounded delays.
Energy efficiency: mobile and idle systems should avoid unnecessary wakeups.
Isolation: one service should not consume all CPU or memory available to others.

These goals conflict. A policy that favors minimum latency may reduce batch throughput. A policy that maximizes throughput may allow interactive work to feel sluggish. Resource management is therefore policy applied to measured workload behavior, not a universal “make the CPU faster” switch.

How CPU Scheduling Works

The kernel represents executable work as tasks. A process provides an address space and resources; threads are the schedulable execution units within it. A task can be in several useful states:

Running: currently executing on a CPU.
Runnable: ready to run but waiting for a CPU.
Sleeping or blocked: waiting for a timer, lock, disk, network response, or another event.
Stopped or terminated: not eligible for normal execution.

The scheduler considers runnable tasks and chooses one for each logical CPU. A context switch saves the outgoing task’s CPU state and restores the incoming task’s state. Context switches are necessary, but they also have cost: caches may be less useful, scheduler bookkeeping consumes CPU time, and frequent switching can reduce throughput.

Time slices and preemption

A time slice is an opportunity for a task to run before the scheduler considers another task. It is not a simple fixed timer in every modern scheduler. The kernel may preempt when a higher-priority task wakes, when a task exhausts its fair share, or when load balancing requires migration.

Short slices can improve responsiveness but increase switching overhead. Long slices help CPU-bound batch work but can increase interactive latency. Modern Linux’s fair scheduling behavior accounts for runnable-task weight rather than exposing one universal slice setting for administrators.

SMP and CPU affinity

On symmetric multiprocessing systems, each CPU can execute a task. The scheduler periodically balances runnable work between CPUs, but moving a task can invalidate useful cache state. CPU affinity lets an administrator restrict a process or thread to selected CPUs when isolation is more important than automatic balancing.

# Inspect the CPUs available to a process
taskset -cp 1234

# Restrict an existing process to CPU 2
sudo taskset -cp 2 1234

# Start a command on CPUs 0 and 1
taskset -c 0,1 ./worker

Affinity can help reserve CPUs for real-time or database workloads, but it can also create an artificial bottleneck. Measure runnable queue length and application latency before keeping a pinning rule.

Scheduling Policies and Priorities

Most general-purpose workloads use a fair scheduling policy. The scheduler attempts to distribute CPU time according to task weights. A process’s niceness changes that weight: a higher nice value makes it less favored, while a negative value makes it more favored and normally requires elevated privileges.

# Start a CPU-heavy batch job with lower priority
nice -n 10 ./large-report

# Change the niceness of an existing process
sudo renice 10 -p 1234

# Inspect process state, priority, and CPU usage
ps -eo pid,cls,pri,ni,stat,pcpu,comm --sort=-pcpu | head

Nice values are relative scheduling preferences, not CPU quotas. A low-priority process can still consume a complete CPU when nothing else is runnable. Conversely, increasing priority cannot create CPU capacity that does not exist.

Linux also supports real-time policies such as SCHED_FIFO and SCHED_RR. These are designed for tasks with strict timing requirements and can preempt ordinary fair-scheduled work. A real-time task that loops without blocking can starve essential services, so real-time permissions and runtime limits must be handled carefully. The POSIX scheduling specification defines portable terms and interfaces for scheduling concepts, but operating systems may expose additional behavior and constraints.

Policy or control	Main purpose	Important risk or trade-off
Fair scheduling	Share CPU time among ordinary tasks	Latency varies under contention
Nice value	Adjust relative preference	Not an absolute CPU limit
`SCHED_FIFO`	Run a real-time task until it blocks or yields	A runaway task can starve the system
`SCHED_RR`	Share time among real-time tasks of equal priority	Requires careful priority design
CPU affinity	Keep work on selected CPUs	Can prevent useful load balancing
cgroup CPU control	Bound or weight a group of tasks	Limits apply to the group, not just one process

Resource Management Beyond the CPU

CPU scheduling is only one part of resource management. A program that appears slow may be runnable but waiting on memory or I/O.

Memory

Virtual memory gives each process an address space that is larger or differently arranged than physical RAM. The kernel maps virtual pages to physical memory and may reclaim cold pages or write them to swap. When available memory becomes scarce, reclaim and page faults compete with application work. Excessive swapping can create a feedback loop in which the machine spends more time moving pages than running applications.

Useful first checks include:

free -h
vmstat 1 5
ps -eo pid,pmem,rss,vsz,comm --sort=-pmem | head

Do not treat swap usage alone as proof of a problem. Examine page-in/page-out activity, latency, and application behavior. A small amount of inactive data in swap can coexist with a healthy system.

I/O

A thread blocked on storage is not consuming CPU while it waits, but its application may still have poor latency. The kernel’s I/O schedulers, device queue depth, filesystem, and storage hardware all influence completion time. Use iostat or equivalent tooling to distinguish CPU saturation from a device queue that is full.

# Sample device utilization and latency
iostat -xz 1 5

# Show processes with notable I/O activity
sudo iotop -o

Control groups

Control groups, or cgroups, group processes and apply resource controls. They can limit or weight CPU time, constrain memory, and account for I/O. Containers rely on namespaces for visibility and cgroups for many resource limits; this is why a container is not automatically entitled to an entire host CPU.

For a broader comparison of the isolation model, see our guide to containerization versus virtualization. Resource limits should be chosen from observed demand and service-level objectives rather than copied from another host.

Practical Diagnostics Workflow

When a service is slow, begin with a question: is it using CPU, waiting for memory, blocked on I/O, or waiting for another task? A short, repeatable workflow is more reliable than changing scheduler knobs at random.

# Overall load, runnable tasks, and CPU view
uptime
top

# Per-thread CPU usage for a process
top -H -p 1234

# Scheduling policy and CPU affinity
chrt -p 1234
taskset -cp 1234

# Scheduler and context-switch counters
pidstat -w -p 1234 1 5

The load average is not a direct percentage of CPU utilization. It generally represents work that is runnable or in uninterruptible sleep, depending on platform accounting. Compare it with the number of logical CPUs and with per-CPU utilization. A high load with idle CPUs can indicate I/O waits or a locking problem rather than insufficient compute.

For deeper analysis, use tracing or profiling tools such as perf, ftrace, or eBPF-based observability. Record a baseline, change one variable, and repeat the same workload. The Linux kernel tuning guide covers the broader discipline of measuring before changing kernel settings.

Scheduling in Containers and Services

Schedulers operate on host tasks even when those tasks belong to containers or service managers. A container runtime may create a cgroup for each container and apply CPU shares, quotas, or cpusets. If a container has a quota equivalent to half a CPU, increasing process priority inside the container cannot bypass that cgroup ceiling.

For systemd-managed services, resource controls can be expressed in a unit or drop-in:

[Service]
CPUQuota=200%
MemoryMax=2G
TasksMax=512

After changing a drop-in, reload units and restart only when appropriate:

sudo systemctl daemon-reload
sudo systemctl restart example.service
systemctl show example.service -p CPUQuota -p MemoryMax -p TasksMax

These controls are useful for protecting a host from a runaway service, but they can also cause timeouts if set below normal burst requirements. Observe throttling and memory events alongside application metrics. For service lifecycle and troubleshooting, see managing systemd services.

Common Misconceptions

A high CPU percentage always means the scheduler is broken. A CPU-bound workload may be using the resource exactly as intended. Determine whether it is meeting its latency or throughput target before changing priorities.

Increasing process priority creates more CPU capacity. Priority changes who wins contention; it does not add cores. Raising one task can make another task less responsive and can starve critical work.

Containers have their own independent scheduler. Containers normally use the host kernel scheduler. Namespaces change what a process can see, while cgroups and runtime settings constrain resource use.

Load average is the same as CPU utilization. Load includes tasks waiting in states that may not be actively executing. Interpret it with CPU count, I/O metrics, run queues, and application latency.