> > 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>