X-Git-Url: http://git.onelab.eu/?a=blobdiff_plain;f=Documentation%2Fvm%2Fovercommit-accounting;h=9db560eba20395979d95610c09ff8dc3ff3c73d4;hb=c7b5ebbddf7bcd3651947760f423e3783bbe6573;hp=e0fd0b8f037aae48ce5e5acea377025e6d180da9;hpb=a2c21200f1c81b08cb55e417b68150bba439b646;p=linux-2.6.git

diff --git a/Documentation/vm/overcommit-accounting b/Documentation/vm/overcommit-accounting
index e0fd0b8f0..9db560eba 100644
--- a/Documentation/vm/overcommit-accounting
+++ b/Documentation/vm/overcommit-accounting
@@ -1,4 +1,4 @@
-The Linux kernel supports three overcommit handling modes
+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
@@ -7,10 +7,10 @@ The Linux kernel supports three overcommit handling modes
 		allocate slighly more memory in this mode. This is the 
 		default.
 
-1	-	No overcommit handling. Appropriate for some scientific
+1	-	Always overcommit. Appropriate for some scientific
 		applications.
 
-2	-	(NEW) strict overcommit. The total address space commit
+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
@@ -27,7 +27,7 @@ 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 is does
+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.