Short answer

• Linux cgroups control CPU either by relative weighting (shares/weight) or by absolute quota (CFS quota / cpu.max).
• Shares/weight only affect scheduling when CPU is contended. Quota enforces a hard time-slice limit.

Key details

1. Two modes

• Relative (fair-share):
  • cgroup v1: cpu.shares (default 1024). Higher = more CPU when contended.
  • cgroup v2: cpu.weight (1–10000, default 100). Same idea; no hard cap.
• Absolute (time quota):
  • cgroup v1 (CFS): cpu.cfs_period_us and cpu.cfs_quota_us.
  • cgroup v2: cpu.max with two fields: “<quota> <period>” or “max <period>” (no limit).

2. How quota works (formula)

• Allowed CPU cores = cpu.cfs_quota_us / cpu.cfs_period_us (v1) or quota/period (v2).
• Percent of a single core = (quota / period) * 100%.
• Percent of total system CPUs = (quota / period) / N_CPUS * 100%. Examples (assume period = 100000 µs = 100 ms):
  • quota = 50000 → 50% of one CPU (0.5 core).
  • quota = 100000 → 100% of one CPU (1 core).
  • quota = 200000 → 200% (2 cores worth of CPU time).

3. Defaults & behavior

• Typical default CFS period: 100000 µs (100 ms). Default quota = -1 (no limit) in v1; v2 default is “max” (unlimited).
• Shares/weight do not limit CPU if the system is idle; they only proportionally divide CPU when multiple cgroups compete.
• Quota always limits usage (even if idle it prevents burst beyond configured budget).
• cpuset.cpus restricts which logical CPUs the group can run on — quota cannot exceed that available CPU-set.

4. Real-time tasks

• Separate controls exist for RT: cpu.rt_period_us and cpu.rt_runtime_us (v1) or related fields in v2; they limit RT runtime to avoid starving normal tasks.

Commands (examples)

View v1:

cat /sys/fs/cgroup/cpu/<group>/cpu.cfs_period_us
cat /sys/fs/cgroup/cpu/<group>/cpu.cfs_quota_us
cat /sys/fs/cgroup/cpu/<group>/cpu.shares

Set v1:

# set period to 100ms and quota to 200ms (2 CPUs)
echo 100000 > /sys/fs/cgroup/cpu/<group>/cpu.cfs_period_us
echo 200000 > /sys/fs/cgroup/cpu/<group>/cpu.cfs_quota_us

View v2:

cat /sys/fs/cgroup/<group>/cpu.max
cat /sys/fs/cgroup/<group>/cpu.weight

Set v2:

# allow 2 CPUs (200ms per 100ms period)
echo "200000 100000" > /sys/fs/cgroup/<group>/cpu.max

# remove quota (unlimited)
echo "max 100000" > /sys/fs/cgroup/<group>/cpu.max

Practical tips

• Use quota for strict limits (e.g., containers). Use shares/weight to balance under contention.
• Choose period carefully (shorter periods = finer granularity but slightly higher overhead).
• Always consider cpuset limits and number of host CPUs when computing percentages.

If you want, give your target (e.g., “limit to 30% of 8‑CPU host”) and I’ll compute exact quota/period values and example commands.

madalinignisca: I want Relative (fair-share) for max 6 physical cores, 12 logical cores, on a cpu that has 32 physical cores. The containers will run allowed on all cpus for spreading their load better. What quota should I put to this container?

GitHub Copilot: – Assumption: host = 32 physical → 64 logical CPUs; you want max = 6 physical = 12 logical.

Short answer (relative / fair‑share — no hard cap)

• cgroup v1 (cpu.shares): 12 * 1024 = 12288
• cgroup v2 (cpu.weight): 12 * 100 = 1200

This gives the container ~12/64 = 18.75% of CPU when the system is fully contested.

Commands

# set cgroup v1 shares
echo 12288 > /sys/fs/cgroup/cpu/<group>/cpu.shares

# set cgroup v2 weight
echo 1200 > /sys/fs/cgroup/<group>/cpu.weight

Notes

• Shares/weight only affect scheduling under contention; they do not enforce a hard limit.
• If you need a hard cap, use cpu.cfs_quota_us/cpu.cfs_period_us (v1) or cpu.max (v2) instead.