The memory controllers allow for both soft and hard limits, so you can set a soft limit of 80% (so if the cgroup is above 80%, its memory will be the first to go) and a hard limit of 100% (so the cgroup get to use all memory no one else wants).
The CPU controller works slightly differently, you can sets a "shares" value, and *when cpu contention occurs* the cpu resources will be assigned proportionally. As the root cgroup defaults to 1024 shares, if you assign a shares value of 4096 to your cgroup (assuming there is no other cgroups), it will be limited to 80% of cpu time when there is contention, but be allowed to use more if no other process wants to be scheduled.
Posted Nov 15, 2012 20:01 UTC (Thu) by glommer (subscriber, #15592)
[Link]
Your description is precise and correct.
However, there are many scenarios where you actually want to limit the maximum amount of cpu used, even without contention. An example of this, is cloud deployments where you pay for cpu time and value price predictability over performance.
The cpu cgroup *also* allows one to set a maximum quota through the combination of the following knobs:
cpu.cfs_quota_us
cpu.cfs_period_us
If you define your quota as 50 % of your period, you will run for at most 50 % of the time. This is bandwidth based, in units of microseconds. So "use at most 2 cpus" is equivalent to 200 %. IOW, 2 seconds per second.
This is defaulted to -1, meaning "no upcap"
Equivalent mechanism exists for rt tasks: cpu.rt_quota_us, etc.
Cheers
Conflicting goals?
Posted Nov 19, 2012 3:14 UTC (Mon) by mathstuf (subscriber, #69389)
[Link]
How does/would the 200% percentage work with big.LITTLE?