Linux-2.6.12-rc2v2.6.12-rc2

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!

1 files changed, 73 insertions, 0 deletions

diff --git a/Documentation/vm/overcommit-accounting b/Documentation/vm/overcommit-accounting
new file mode 100644
index 000000000000..21c7b1f8f32b
--- /dev/null
+++ b/Documentation/vm/overcommit-accounting
@@ -0,0 +1,73 @@
+The Linux kernel supports the following overcommit handling modes
+
+0       -       Heuristic overcommit handling. Obvious overcommits of
+                address space are refused. Used for a typical system. It
+                ensures a seriously wild allocation fails while allowing
+                overcommit to reduce swap usage.  root is allowed to 
+                allocate slighly more memory in this mode. This is the 
+                default.
+
+1       -       Always overcommit. Appropriate for some scientific
+                applications.
+
+2       -       Don't overcommit. The total address space commit
+                for the system is not permitted to exceed swap + a
+                configurable percentage (default is 50) of physical RAM.
+                Depending on the percentage you use, in most situations
+                this means a process will not be killed while accessing
+                pages but will receive errors on memory allocation as
+                appropriate.
+
+The overcommit policy is set via the sysctl `vm.overcommit_memory'.
+
+The overcommit percentage is set via `vm.overcommit_ratio'.
+
+The current overcommit limit and amount committed are viewable in
+/proc/meminfo as CommitLimit and Committed_AS respectively.
+
+Gotchas
+-------
+
+The C language stack growth does an implicit mremap. If you want absolute
+guarantees and run close to the edge you MUST mmap your stack for the 
+largest size you think you will need. For typical stack usage this does
+not matter much but it's a corner case if you really really care
+
+In mode 2 the MAP_NORESERVE flag is ignored. 
+
+
+How It Works
+------------
+
+The overcommit is based on the following rules
+
+For a file backed map
+        SHARED or READ-only     -       0 cost (the file is the map not swap)
+        PRIVATE WRITABLE        -       size of mapping per instance
+
+For an anonymous or /dev/zero map
+        SHARED                  -       size of mapping
+        PRIVATE READ-only       -       0 cost (but of little use)
+        PRIVATE WRITABLE        -       size of mapping per instance
+
+Additional accounting
+        Pages made writable copies by mmap
+        shmfs memory drawn from the same pool
+
+Status
+------
+
+o       We account mmap memory mappings
+o       We account mprotect changes in commit
+o       We account mremap changes in size
+o       We account brk
+o       We account munmap
+o       We report the commit status in /proc
+o       Account and check on fork
+o       Review stack handling/building on exec
+o       SHMfs accounting
+o       Implement actual limit enforcement
+
+To Do
+-----
+o       Account ptrace pages (this is hard)