summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorKubernetes Submit Queue <k8s-merge-robot@users.noreply.github.com>2016-09-03 09:11:15 -0700
committerGitHub <noreply@github.com>2016-09-03 09:11:15 -0700
commitf1f7f2e6f42e198ac7c8d1257068dddc14b01aad (patch)
tree7e24c46de21e66e9d5d7915a5d4e2d65ef821ddf
parent9bff312b3dccd8de754cce77f4cda0627c0f484f (diff)
parent40d31aca4282817172fc90c912d4285e6945942b (diff)
Merge pull request #31861 from YuPengZTE/devNote
Automatic merge from submit-queue The first letter is small <!-- Thanks for sending a pull request! Here are some tips for you: 1. If this is your first time, read our contributor guidelines https://github.com/kubernetes/kubernetes/blob/master/CONTRIBUTING.md and developer guide https://github.com/kubernetes/kubernetes/blob/master/docs/devel/development.md 2. If you want *faster* PR reviews, read how: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/faster_reviews.md 3. Follow the instructions for writing a release note: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/pull-requests.md#release-notes --> **What this PR does / why we need it**: **Which issue this PR fixes** *(optional, in `fixes #<issue number>(, #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes # **Special notes for your reviewer**: **Release note**: <!-- Steps to write your release note: 1. Use the release-note-* labels to set the release note state (if you have access) 2. Enter your extended release note in the below block; leaving it blank means using the PR title as the release note. If no release note is required, just write `NONE`. --> ```release-note ```
-rw-r--r--resource-qos.md2
1 files changed, 1 insertions, 1 deletions
diff --git a/resource-qos.md b/resource-qos.md
index af84b648..b2a43c97 100644
--- a/resource-qos.md
+++ b/resource-qos.md
@@ -228,7 +228,7 @@ Pod OOM score configuration
- OOM_SCORE_ADJ: -998
*Kubelet, Docker*
- OOM_SCORE_ADJ: -999 (won’t be OOM killed)
- - Hack, because these critical tasks might die if they conflict with guaranteed containers. in the future, we should place all user-pods into a separate cgroup, and set a limit on the memory they can consume.
+ - Hack, because these critical tasks might die if they conflict with guaranteed containers. In the future, we should place all user-pods into a separate cgroup, and set a limit on the memory they can consume.
## Known issues and possible improvements