c9c2f644da
In each options/foo.md, keep a list of where the option is used. This will be valuable to anyone making future edits, and to those reviewing those edits. This may be a controversial commit, because those crossref lists are autogenerated as a side effect of the script that reads them. It definitely violates POLA. And one day, some kind person will reconcile (e.g.) --label, using it in more man pages, and maybe forget to git-commit the rewritten file, and CI will fail. I think this is a tough tradeoff, but worth doing. Without this, it's much too easy for someone to change an option file in a way that renders it inapplicable/misleading for some podman commands. Signed-off-by: Ed Santiago <santiago@redhat.com>
2.2 KiB
####> This option file is used in: ####> podman build, container clone, create, pod clone, pod create, run, update ####> If you edit this file, make sure your changes ####> are applicable to all of those.
--cpu-shares, -c=shares
CPU shares (relative weight).
By default, all containers get the same proportion of CPU cycles. This proportion can be modified by changing the container's CPU share weighting relative to the combined weight of all the running containers. Default weight is 1024.
The proportion will only apply when CPU-intensive processes are running. When tasks in one container are idle, other containers can use the left-over CPU time. The actual amount of CPU time will vary depending on the number of containers running on the system.
For example, consider three containers, one has a cpu-share of 1024 and two others have a cpu-share setting of 512. When processes in all three containers attempt to use 100% of CPU, the first container would receive 50% of the total CPU time. If a fourth container is added with a cpu-share of 1024, the first container only gets 33% of the CPU. The remaining containers receive 16.5%, 16.5% and 33% of the CPU.
On a multi-core system, the shares of CPU time are distributed over all CPU cores. Even if a container is limited to less than 100% of CPU time, it can use 100% of each individual CPU core.
For example, consider a system with more than three cores. If the container C0 is started with --cpu-shares=512 running one process, and another container C1 with --cpu-shares=1024 running two processes, this can result in the following division of CPU shares:
| PID | container | CPU | CPU share |
|---|---|---|---|
| 100 | C0 | 0 | 100% of CPU0 |
| 101 | C1 | 1 | 100% of CPU1 |
| 102 | C1 | 2 | 100% of CPU2 |
On some systems, changing the resource limits may not be allowed for non-root users. For more details, see https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error
This option is not supported on cgroups V1 rootless systems.