quoted

3) overcommit 2gb hugepages.
mmap(NULL, 18446744071562067968, PROT_READ|PROT_WRITE, MAP_SHARED,
3, 0) = -1 ENOMEM (Cannot allocate memory)

Hmm, you are trying to reserve/mmap a lot of memory (17179869182 1GB
huge pages).

That is strange - the test code merely did this,
addr = mmap(ADDR, 2<<30, PROTECTION, FLAGS, fd, 0);

Do you know if overcommit was designed for 1GB pages? At least, read this
from Documentation/kernel-parameters.txt,

hugepagesz=
              ...
             Note that 1GB pages can only be allocated at boot time
             using hugepages= and not freed afterwards.

How does it allow to be overcommitted for only being able to allocate at
boot time?

quoted

Also, nr_overcommit_hugepages was overwritten with such a strange
value after overcommit failure. Should we just remove this file from
sysfs for simplicity?

This is strange. The value is set only in hugetlb_overcommit_handler
which is a sysctl handler.

Are you sure that you are not changing the value by the /sys interface
somewhere (there is no check for the value so you can set what-ever
value you like)? I fail to see any mmap code path which would change
this value.

I could double-check here, but it is not important if the fact is that
overcommit is not supported for 1GB pages.

Btw. which kernel version are you using.

mmotm 2010-12-02-16-34 version 2.6.37-rc4-mm1+. This problem is also present
in 2.6.18.

Thanks.

CAI Qian

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>