docs: fix cpu.shares part in man pages

The original description has some mistakes and lack of many useful
information, I rewrite them to make it accurate and complete.

Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
This commit is contained in:
Qiang Huang 2015-03-03 11:15:34 +08:00 committed by Tibor Vass
parent 80728bcd7b
commit ef5874f0a9
1 changed files with 27 additions and 16 deletions

View File

@ -423,24 +423,35 @@ We have four ways to set memory usage:
It is not allowed to use more than L bytes of memory, swap *plus* memory It is not allowed to use more than L bytes of memory, swap *plus* memory
usage is limited by S. usage is limited by S.
The operator can increase the priority of this container with The operator can modify the priority of this container with
the `-c` option. By default, all containers run at the same priority and the `-c` option. By default, all containers run at the same priority
get the same proportion of CPU cycles, but you can tell the kernel to and get the same proportion of CPU cycles, the value specified must be 2
give more shares of CPU time to one or more containers when you start or higher, if you are not setting `-c` or `--cpu-shares`, the default
them via Docker. shares of CPU time would be 1024.
The flag `-c` or `--cpu-shares` with value 0 indicates that the running CPU shares is kind of CPU bandwidth weight, the proportion will only
container has access to all 1024 (default) CPU shares. However, this value reflect when CPU-intensive processes are running. When tasks in one
can be modified to run a container with a different priority or different container are idle, other containers are allowed to borrow the left-over
proportion of CPU cycles. CPU time.
E.g., If we start three {C0, C1, C2} containers with default values The actual amount of CPU time can very depending on the number of containers
(`-c` OR `--cpu-shares` = 0) and one {C3} with (`-c` or `--cpu-shares`=512) running on the system. If a container have a share of 1024 and two other
then C0, C1, and C2 would have access to 100% CPU shares (1024) and C3 would containers have share of 512, when processes in all containers attempt to
only have access to 50% CPU shares (512). In the context of a time-sliced OS use 100% of CPU, the first container would receive 50% of all CPU time, if
with time quantum set as 100 milliseconds, containers C0, C1, and C2 will run another container with share of 1024 is added, the first container would
for full-time quantum, and container C3 will run for half-time quantum i.e 50 only get 33% of the CPU (the rest receive 16.5%, 16.5% and 33% of CPU).
milliseconds.
Note that shares of CPU time are distributed per all CPU cores on multi-core
systems. Even if a container is limited to less than 100% of CPU time, it
may use 100% of each individual CPU core. E.g., if we start {C0} container
with (`-c` = 512) and {C1} with (`-c` = 1024), we start three CPU-intensive
processes (one in {C0} and two in {C1}) on a system with more than three
cores, might results 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
## Runtime privilege, Linux capabilities, and LXC configuration ## Runtime privilege, Linux capabilities, and LXC configuration