combined memory and swap that can be used, while `--memory` is only the amount
of physical memory that can be used.
### `--memory-swappiness` details
- A value of 0 turns off anonymous page swapping.
- A value of 100 sets all anonymous pages as swappable.
- By default, if you don't set `--memory-swappiness`, the value is
inherited from the host machine.
### `--kernel-memory` details
Kernel memory limits are expressed in terms of the overall memory allocated to
a container. Consider the following scenarios:
- **Unlimited memory, unlimited kernel memory**: This is the default
behavior.
- **Unlimited memory, limited kernel memory**: This is appropriate when the
amount of memory needed by all cgroups is greater than the amount of
memory that actually exists on the host machine. You can configure the
kernel memory to never go over what's available on the host machine,
and containers which need more memory need to wait for it.
- **Limited memory, unlimited kernel memory**: The overall memory is
limited, but the kernel memory isn't.
- **Limited memory, limited kernel memory**: Limiting both user and kernel
memory can be useful for debugging memory-related problems. If a container
is using an unexpected amount of either type of memory, it runs out
of memory without affecting other containers or the host machine. Within
this setting, if the kernel memory limit is lower than the user memory
limit, running out of kernel memory causes the container to experience
an OOM error. If the kernel memory limit is higher than the user memory
limit, the kernel limit doesn't cause the container to experience an OOM.
When you enable kernel memory limits, the host machine tracks the "high water mark"
statistics on a per-process basis, so you can track which processes (in this
case, containers) are using excess memory. This can be seen per process by
viewing `/proc/<PID>/status` on the host machine.
## CPU
By default, each container's access to the host machine's CPU cycles is unlimited.
You can set various constraints to limit a given container's access to the host
machine's CPU cycles. Most users use and configure the
[default CFS scheduler](#configure-the-default-cfs-scheduler). You can also
configure the [real-time scheduler](#configure-the-real-time-scheduler).
### Configure the default CFS scheduler
The CFS is the Linux kernel CPU scheduler for normal Linux processes. Several
runtime flags let you configure the amount of access to CPU resources your
container has. When you use these settings, Docker modifies the settings for
the container's cgroup on the host machine.
| Option | Description |
| :--------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `--cpus=<value>` | Specify how much of the available CPU resources a container can use. For instance, if the host machine has two CPUs and you set `--cpus="1.5"`, the container is guaranteed at most one and a half of the CPUs. This is the equivalent of setting `--cpu-period="100000"` and `--cpu-quota="150000"`. |