diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/cgroups/memcg_test.txt | 24 | ||||
| -rw-r--r-- | Documentation/filesystems/proc.txt | 28 |
2 files changed, 50 insertions, 2 deletions
diff --git a/Documentation/cgroups/memcg_test.txt b/Documentation/cgroups/memcg_test.txt index 19533f93b7a2..523a9c16c400 100644 --- a/Documentation/cgroups/memcg_test.txt +++ b/Documentation/cgroups/memcg_test.txt @@ -1,6 +1,6 @@ Memory Resource Controller(Memcg) Implementation Memo. -Last Updated: 2008/12/15 -Base Kernel Version: based on 2.6.28-rc8-mm. +Last Updated: 2009/1/19 +Base Kernel Version: based on 2.6.29-rc2. Because VM is getting complex (one of reasons is memcg...), memcg's behavior is complex. This is a document for memcg's internal behavior. @@ -340,3 +340,23 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y. # mount -t cgroup none /cgroup -t cpuset,memory,cpu,devices and do task move, mkdir, rmdir etc...under this. + + 9.7 swapoff. + Besides management of swap is one of complicated parts of memcg, + call path of swap-in at swapoff is not same as usual swap-in path.. + It's worth to be tested explicitly. + + For example, test like following is good. + (Shell-A) + # mount -t cgroup none /cgroup -t memory + # mkdir /cgroup/test + # echo 40M > /cgroup/test/memory.limit_in_bytes + # echo 0 > /cgroup/test/tasks + Run malloc(100M) program under this. You'll see 60M of swaps. + (Shell-B) + # move all tasks in /cgroup/test to /cgroup + # /sbin/swapoff -a + # rmdir /test/cgroup + # kill malloc task. + + Of course, tmpfs v.s. swapoff test should be tested, too. diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index bbebc3a43ac0..a87be42f8211 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -2027,6 +2027,34 @@ increase the likelihood of this process being killed by the oom-killer. Valid values are in the range -16 to +15, plus the special value -17, which disables oom-killing altogether for this process. +The process to be killed in an out-of-memory situation is selected among all others +based on its badness score. This value equals the original memory size of the process +and is then updated according to its CPU time (utime + stime) and the +run time (uptime - start time). The longer it runs the smaller is the score. +Badness score is divided by the square root of the CPU time and then by +the double square root of the run time. + +Swapped out tasks are killed first. Half of each child's memory size is added to +the parent's score if they do not share the same memory. Thus forking servers +are the prime candidates to be killed. Having only one 'hungry' child will make +parent less preferable than the child. + +/proc/<pid>/oom_score shows process' current badness score. + +The following heuristics are then applied: + * if the task was reniced, its score doubles + * superuser or direct hardware access tasks (CAP_SYS_ADMIN, CAP_SYS_RESOURCE + or CAP_SYS_RAWIO) have their score divided by 4 + * if oom condition happened in one cpuset and checked task does not belong + to it, its score is divided by 8 + * the resulting score is multiplied by two to the power of oom_adj, i.e. + points <<= oom_adj when it is positive and + points >>= -(oom_adj) otherwise + +The task with the highest badness score is then selected and its children +are killed, process itself will be killed in an OOM situation when it does +not have children or some of them disabled oom like described above. + 2.13 /proc/<pid>/oom_score - Display current oom-killer score ------------------------------------------------------------- |