In this lesson, you will learn how the Linux kernel balances competing demands for finite hardware resources when containers are configured to use more capacity than the underlying host actually provides.
The Reality of Overcommitment
In a containerized environment, "overcommitment" occurs when the sum of requests (guaranteed resources) and limits (hard caps) across all containers exceeds the physical capacity of the host. The kernel manages this through the Completely Fair Scheduler (CFS) and the Out-of-Memory (OOM) Killer. Rather than simply crashing when resources are exhausted, the kernel uses priority scoring to make tactical decisions about which processes to sacrifice.
Kernel-Level Fair-Share Algorithms
The kernel treats container resource allocation as a weighted scheduling problem. By manipulating cpu.shares in the Control Groups (cgroups) filesystem, you define the relative "weight" of a container. If you have two containers—one with 1024 shares and another with 512—the kernel ensures that under heavy contention, the first container receives twice the CPU cycles of the second. This is a "fair-share" mechanism; it doesn't give a hard guarantee, but it ensures mathematical proportionality during contention.
For memory, the kernel employs a hierarchical scoring system. Each container is assigned an oom_score_adj. When memory pressure hits the host and the kernel cannot reclaim enough pages, it scans for the process with the highest score.
Managing Priority via cgroups
You can influence these kernel decisions by adjusting the tuning knobs within the cgroup hierarchy. For example, to prioritize a mission-critical container, you increase its share weight relative to others:
# Set the CPU weight for a container group (cgroup v2)
echo 2048 > /sys/fs/cgroup/web-app/cpu.weight
# Lower the OOM score adjustment so the kernel kills this container last
echo -500 > /sys/fs/cgroup/web-app/memory.oom.group
By setting a negative oom.group value, you signal to the kernel that this specific container is "critical," effectively protecting it from being the first target during a host-wide memory shortage. This interplay between weight-based scheduling and OOM prioritization allows you to run high-density workloads safely, provided you have strictly defined your priority tiers.
Key Takeaway: Resource overcommitment relies on the kernel's ability to map abstract container weights into proportional CPU cycles and OOM-protection scores, ensuring that lower-priority processes are sacrificed before critical services under contention.