HTTP Expert

Tag: cgroup

  • Explain how is allowence limit for cpu in cgroups for Linux

    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).
    1. 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).
    1. 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.
    1. 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.