Techwizz/kernel-fxtec-pro1x
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Documentation: correct overcommit caveat in hugetlbpage.txt

Browse source 
As shown by Gurudas Pai recently, we can put hugepages into the surplus
state (by echo 0 > /proc/sys/vm/nr_hugepages), even when
/proc/sys/vm/nr_overcommit_hugepages is 0. This is actually correct, to
allow the original goal (shrink the static pool to 0) to succeed (we are
converting hugepages to surplus because they are in use). However, the
documentation does not accurately reflect this case. Update it.

Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Acked-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This commit is contained in:
Nishanth Aravamudan 2008-04-15 14:34:43 -07:00 committed by Linus Torvalds
parent 91446b064c
commit 423bec4307
1 changed files with 3 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

7
Documentation/vm/hugetlbpage.txt
View file

@ -88,10 +88,9 @@ hugepages from the buddy allocator, if the normal pool is exhausted. As
these surplus hugepages go out of use, they are freed back to the buddy
allocator.
Caveat: Shrinking the pool via nr_hugepages while a surplus is in effect
will allow the number of surplus huge pages to exceed the overcommit
value, as the pool hugepages (which must have been in use for a surplus
hugepages to be allocated) will become surplus hugepages. As long as
Caveat: Shrinking the pool via nr_hugepages such that it becomes less
than the number of hugepages in use will convert the balance to surplus
huge pages even if it would exceed the overcommit value. As long as
this condition holds, however, no more surplus huge pages will be
allowed on the system until one of the two sysctls are increased
sufficiently, or the surplus huge pages go out of use and are freed.