CentOS6/7下Cgroup中cpu.shares与cpu.cfs_quota_us的关联及优先级疑问

Great question—this is a super common point of confusion when tuning CPU resources with cgroups. Let’s break down how these two settings work alone, then how they interact when used together:

First, What Each Setting Does #

Let’s start with quick, practical definitions to set the stage:

• cpu.shares: This is a relative weight that only kicks in when CPU resources are contended (i.e., multiple cgroups are fighting for CPU time). It doesn’t cap usage—if the system has idle CPU, a cgroup with low shares can still use 100% of available cores. When there’s competition, CPU time is split proportionally to the shares values. For example, a cgroup with shares=2048 will get twice as much CPU time as one with shares=1024 when both are maxed out.
• cpu.cfs_quota_us (paired with cpu.cfs_period_us): This is a hard cap on CPU usage, regardless of system load. The cfs_period_us defines a time window (default 100ms, or 100000 microseconds), and cfs_quota_us sets the maximum CPU time the cgroup can use in that window. For example, cfs_quota_us=50000 means the cgroup can use at most 50ms of CPU per 100ms window—so 50% of a single core’s capacity (adjust this if you’ve bound the cgroup to multiple cores with cpu.cpus).

How They Work Together #

These settings don’t override each other, and there’s no strict "priority"—they work in tandem to shape CPU allocation:

1. The hard cap (cfs_quota_us) always applies first: No matter how much idle CPU is available, the cgroup will never use more CPU time than the quota allows per period. Even if the system is completely idle, a cgroup with cfs_quota_us=50000 can’t use more than 50% of a core.
2. cpu.shares only takes effect when there’s CPU competition and cgroups haven’t hit their quota caps: If multiple cgroups are all trying to use CPU, and none have reached their cfs_quota_us limits, CPU time is split according to the shares ratio.

Example Scenarios #

Let’s make this concrete with two examples on a single-core system:

• Scenario 1: Both cgroups have quota set to full core capacity
  • Group A: cfs_quota_us=100000 (100% core), shares=1024
  • Group B: cfs_quota_us=100000 (100% core), shares=2048
  • When both groups are running CPU-heavy tasks, they’ll split the core in a 1:2 ratio—Group A gets ~33% of CPU time, Group B gets ~67%. The quota doesn’t restrict them here (since they’re under the 100% cap), so shares dictate the split.
• Scenario 2: One cgroup has a strict quota
  • Group A: cfs_quota_us=50000 (50% core), shares=1024
  • Group B: cfs_quota_us=100000 (100% core), shares=1024
  • When both are maxed out, Group A can only use 50% of the core (due to quota). The remaining 50% goes entirely to Group B—even though their shares are equal, Group A’s cap means there’s no "competition" for that extra 50%, so shares don’t factor in here.

Key Takeaway #

• Use cfs_quota_us when you need to guarantee a hard upper limit on CPU usage (e.g., to prevent a process from hogging resources).
• Use cpu.shares to prioritize which cgroups get more CPU time when resources are tight, without restricting their ability to use idle CPU.
• When combined, the quota acts as a ceiling, and shares govern how available CPU time is split below that ceiling when there’s competition.

内容的提问来源于stack exchange，提问作者magodo