> > 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?
> > 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@xxxxxxxxxx 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@xxxxxxxxx";> email@xxxxxxxxx </a>