From a5c18a853e1e481003c143a5985972137078bbba Mon Sep 17 00:00:00 2001 From: Ed Costello Date: Mon, 24 Aug 2015 23:02:44 -0400 Subject: [PATCH] Copy edits for typos Signed-off-by: Ed Costello --- docs/reference/run.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/reference/run.md b/docs/reference/run.md index 1dfef0c70f..2ad18b57b2 100644 --- a/docs/reference/run.md +++ b/docs/reference/run.md @@ -668,8 +668,8 @@ limit and "K" the kernel limit. There are three possible ways to set limits: U != 0, K < U Kernel memory is a subset of the user memory. This setup is useful in - deployments where the total amount of memory per-cgroup is overcommited. - Overcommiting kernel memory limits is definitely not recommended, since the + deployments where the total amount of memory per-cgroup is overcommitted. + Overcommitting kernel memory limits is definitely not recommended, since the box can still run out of non-reclaimable memory. In this case, the you can configure K so that the sum of all groups is never greater than the total memory. Then, freely set U at the expense of @@ -679,7 +679,7 @@ limit and "K" the kernel limit. There are three possible ways to set limits: U != 0, K > U - Since kernel memory charges are also fed to the user counter and reclaimation + Since kernel memory charges are also fed to the user counter and reclamation is triggered for the container for both kinds of memory. This configuration gives the admin a unified view of memory. It is also useful for people who just want to track kernel memory usage.