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
 -------------------------------------------------------------