This page is the drill floor for Containers — namespaces, cgroups, difference from VMs . We take the two ideas from the parent — namespaces (what a process can SEE ) and cgroups (what a process can USE ) — and push them through every case that a real machine or an exam can throw at you.
Before we start, one reminder so nothing is used before it's built:
Definition The three numbers cgroups make you compute
quota — how many microseconds of CPU time a group is allowed inside each window. A microsecond (μ s 1 0 − 6 s period — the length of that window in microseconds. The kernel hands out quota fresh every period.memory.max — a byte count. A byte is one character of storage; 1 MiB = 1024 × 1024 = 1048576 not the decimal megabyte). One step up, 1 GiB = 1024 MiB pids.max — a plain count of how many processes (tasks) the group may contain at once. Cross the count and the next fork is refused. This is the fork-bomb brake.
The one formula we reuse:
CPU share = period quota cores Why a ratio and not a subtraction? Because "share of a core" is relative — you want the fraction of each window you're awake, and a fraction is always a division of the part by the whole.
Every question about containers lands in one of these cells. The worked examples below are each tagged with the cell they cover, and together they hit all of them.
#
Case class
The tricky part
Example
A
CPU quota < period (fraction of a core)
share below 1
Ex 1
B
CPU quota = period (exactly one core)
boundary value
Ex 2
C
CPU quota > period (multiple cores)
share above 1
Ex 3
D
Degenerate quota = max (unlimited)
division by "infinity"
Ex 4
E
Memory limit + OOM decision
byte arithmetic, over/under
Ex 5
F
PID namespace numbering
the "PID 1" surprise
Ex 6
G
User namespace UID mapping
root-inside ≠ root-outside
Ex 7
H
Container vs VM word problem
which one, and why
Ex 8
I
Exam twist: cgroup without namespace
isolation vs limits confusion
Ex 9
The next figure is a timeline of one CPU. Time runs left to right; each period is a box; the shaded part of each box is the quota the group is allowed to run. Look at how the fraction filled changes across the four cases — that fraction is the answer. (Case C needs more than one core, so it also needs more than one such timeline — we handle that in words in Ex 3.)
Worked example Ex 1 — Case A:cpu.max = "25000 100000"
A container is configured with cpu.max = "25000 100000". How many cores does it get?
Forecast: guess before reading — is it more or less than a whole core? (The quota box is only partly filled, so… less.)
Read the two numbers: quota = 25000 μ s period = 100000 μ s Why this step? cpu.max always stores "quota period" in that order; the whole calculation needs both, so we name them first.
Apply the formula: 100000 25000 = 0.25 Why this step? We want the fraction of each window the group is awake — see the first shaded box in the figure: a quarter filled.
Interpret: 0.25 cores , i.e. 25% of one CPU.
Verify: units — μ s / μ s 0.25 < 1
Worked example Ex 2 — Case B: exactly one coreFind the cpu.max string that grants exactly one full core , using a 100 ms
Forecast: for the share to equal 1, what must quota be relative to period?
Convert the period: 100 ms = 100000 μ s Why this step? cpu.max speaks microseconds only; mixing milliseconds silently gives an answer off by 1000.
Set the formula equal to 1: 100000 quota = 1 ⇒ quota = 100000 Why this step? "One core" is the boundary case — the shaded box in the figure is completely filled, so quota must equal period.
Write it: cpu.max = "100000 100000".
Verify: 100000/100000 = 1.0
Worked example Ex 3 — Case C: more than one corecpu.max = "300000 100000" on an 8-core machine. Cores granted? Any cap issue?
Forecast: quota is bigger than period — can you even use more than one core's worth in a single window?
Compute: 100000 300000 = 3 Why this step? Same ratio; here the numerator exceeds the denominator, so the answer exceeds 1.
Interpret: 3 cores . In the figure's last panel the box is drawn completely full — that only shows a single core saturated. To actually reach 3 × three cores at the same time , each fully used within the period; imagine three copies of that full box stacked in parallel.
Why this step? A single core can't give more than 100% in one window; the scheduler spreads the extra quota across several cores simultaneously. The scheduler here is the CFS (Completely Fair Scheduler), Linux's default process scheduler — the machinery that decides which task runs on which core and for how long (see Scheduling — CFS and CPU shares ). The figure only draws one core's timeline, so the "3 cores" comes from the arithmetic, not the picture.
Check feasibility: 3 ≤ 8
Verify: 300000/100000 = 3 3 ≤ 8 effective cap would be 2, but the configured share is still 3. ✓
Worked example Ex 4 — Case D (degenerate): unlimited CPUcpu.max = "max 100000". What share is that, and why can't we just plug into the formula?
Forecast: what number, divided by 100000, means "no limit"?
Recognise the literal max: it is not a number , it is the keyword meaning "no quota enforced."
Why this step? Blindly doing max /100000
Interpret the limit conceptually : as quota → ∞ share = quota / period → ∞ uncapped — the group may use every core the scheduler will give it.
Why this step? The degenerate input is the limiting behaviour of Case C pushed to infinity; the shaded region would fill every box on every core.
Answer: unlimited CPU (default for a new cgroup).
Verify: consistency check — Case C with growing quota (1×, 3×, 10× the period) gives 1, 3, 10 cores; the trend has no ceiling, confirming max = ∞ = uncapped. ✓
Worked example Ex 5 — Case E: OOM-kill decisionmemory.max = 268435456. The process's resident memory (RSS) climbs to 250 MiB 260 MiB
Forecast: 268435456
Convert the limit to MiB: 1048576 268435456 = 256 Why this step? The knob is in raw bytes but usage is quoted in MiB; we must compare like with like (see Docker images and layered filesystems (overlayfs) for where these bytes live).
Compare 250 256 250 < 256 safe .
Why this step? The cgroup memory controller only acts when the group's total charged memory exceeds the cap; being under it triggers nothing.
Compare 260 256 260 > 256 reclaim , then if it can't the OOM-killer fires and kills a process in the group .
Why this step? memory.max is a hard ceiling; there is no VM to swap into on the guest's behalf — the same host kernel enforces it.
Verify: 268435456 = 256 × 1048576 250 < 256 ≤ 260
Common mistake Edge case: cgroup memory ≠ just RSSReal systems expose a subtlety. memory.current charges RSS + page cache (the file pages the process read/wrote), not RSS alone. So a process with 250 MiB 30 MiB 280 MiB can be over 256 Why it matters: the kernel can reclaim reclaimable cache first to stay under the cap, and only OOM-kills when even that isn't enough. The clean "RSS vs limit" comparison above is the exam model; the production model is "total charged memory (RSS + reclaimable cache) after reclaim vs limit."
The next figure shows two process tables side by side : the host's table (many PIDs) and the container's private PID-namespace table (renumbered from 1). Follow the red arrow — it's the same running process wearing two different ID badges.
Worked example Ex 6 — Case F: the "PID 1" surpriseOn the host, ps shows your shell as PID 4021. You run unshare --pid --fork --mount-proc bash and inside run echo $$. What PID does it print, and does host-4021 still exist?
Forecast: a fresh PID namespace starts counting from where?
unshare --pid gives the new bash its own PID table.
Why this step? Recall from the parent: each CLONE_NEWPID privatises the one global PID list (built via Processes and the clone/fork syscall ).A new PID namespace numbers from 1 , so the first process in it is PID 1 . echo $$ prints 1.
Why this step? The figure's right table starts at 1; there is simply no other entry yet.
The host view is unchanged: the same process is still PID 4021 in the host namespace (red arrow — one process, two numbers).
Why this step? Namespaces relabel views ; they don't delete the process from the host's accounting.
Verify: two truths coexist — inside PID = 1 = 4021 per namespace it belongs to . ✓
Worked example Ex 7 — Case G: root inside ≠ root outsideA rootless container maps container UIDs 0 … 65535 100000 whoami says root (UID 0). What host UID is that really, and can it delete /etc/passwd on the host?
Forecast: if inside-0 maps to outside-100000, what powers does outside-100000 actually have?
Check the prerequisite: the host must have subordinate UIDs allocated to the launching user, e.g. a line alice:100000:65536 in /etc/subuid. Only then may the user namespace map 0 … 65535 100000 … 165535 Why this step? The kernel refuses a mapping into a range the user was never delegated; without the /etc/subuid grant the unshare --user --map-root simply fails, so the whole example presupposes it.
Apply the mapping: container UID 0 ↦ 0 + 100000 = 100000 Why this step? A user namespace is a shift table: host_uid = map_base + container_uid
Host UID 100000 /etc.
Why this step? Only host UID 0 100000 = 0
Therefore container-root cannot delete the host's /etc/passwd — the write is checked against host UID 100000 and denied.
Verify: 0 + 100000 = 100000 = 0 100000 + 65535 = 165535 ≤ # prompt and whoami=root are inside-namespace truths; the file-permission check uses the host UID. All consistent. ✓
Worked example Ex 8 — Case H (word problem): pick the right boxA team must run 1000 copies of a small Linux web service on one host, each needing ≤ 128 MiB
Forecast: where does the "own kernel" cost bite hardest at 1000×?
Each VM must boot its own guest kernel + base OS, roughly ≥ 512 MiB ≈ 1000 × 512 = 512000 MiB 512000/1024 = 500 GiB Why this step? A VM duplicates a full OS (see Virtualization and Hypervisors (Type 1 vs Type 2) ); that fixed tax multiplies by the count.
Each container shares the one host kernel — its OS overhead is ≈ 0 128 MiB ≈ 1000 × 128 = 128000 MiB = 125 GiB Why this step? One kernel = container; the kernel cost is paid once, not 1000 times.
Decide: same OS, same trust domain, ms startup, huge count → containers .
Verify: VM OS tax = 1000 × 512 = 512000 MiB = 0 500 GiB
Worked example Ex 9 — Case I (exam twist): cgroup but NO namespaceA process is placed in a cgroup with pids.max = 100 and memory.max = 256M, but is given no namespaces . From that process, can you (a) fork-bomb the host, (b) see and kill host PID 4021?
Forecast: which of the two features controls visibility , and did we turn it on?
(a) Fork-bomb: pids.max = 100 caps the group at 100 tasks → the bomb is stopped at 100, the 101st fork is refused.
Why this step? cgroups limit quantity ; the pids controller counts the group's tasks and refuses the next fork past the cap (from Linux Kernel — syscalls ).
(b) Visibility: with no PID namespace , this process shares the host's single global PID table.
Why this step? Isolation of view comes only from namespaces — and we added none.
(b) Result: it can see host PID 4021 in the shared table, and if it runs with sufficient privilege on the host (e.g. as host root, or as the owner of PID 4021) it can kill it — the cgroup never hid the process nor blocked the signal. The pids.max/memory.max limits constrain how much it may consume, not whom it may see or signal.
Why this step? This is the whole point of the twist: caps and isolation are orthogonal. A resource limit does nothing to remove a target from view or to deny a kill syscall the permission check would otherwise allow.
Verify: cgroup caps satisfied (≤ 100 ≤ 256 visible and killable — proving the parent's rule: cgroups = limits, namespaces = isolation; you need both. ✓
Recall Self-test across the whole matrixcpu.max = "50000 200000" gives how many cores? ::: 50000/200000 = 0.25 memory.max = 134217728 is how many MiB? ::: 134217728/1048576 = 128 /etc/subuid contain for that mapping to be allowed? ::: a delegated range for the user, e.g. alice:100000:65536
Cgroup alone, no namespace: can it hide host processes? ::: No — only namespaces isolate view
memory.current charges RSS plus what? ::: reclaimable page cache (so charged memory > RSS)
Mnemonic Matrix in one breathRatio for CPU (quota/period), bytes for memory (÷ 1048576 for MiB), rename for PID (starts at 1), shift for UID (base + id). See = namespaces, Use = cgroups.
Back to the parent topic · prerequisite: Processes and the clone/fork syscall · related: Scheduling — CFS and CPU shares , Networking — virtual interfaces and bridges , Filesystems — mount and chroot .
