On 01/30/2014 01:37 AM, Davidlohr Bueso wrote:
From: Davidlohr Bueso<davidlohr@xxxxxx> While testing some changes, I noticed an issue triggered by the libhugetlbfs test-suite. This is caused by commit 309381fe (mm: dump page when hitting a VM_BUG_ON using VM_BUG_ON_PAGE), where an application can unexpectedly OOM due to another program that using, or reserving, pool_size-1 pages later triggers a VM_BUG_ON_PAGE and thus greedly leaves no memory to the rest of the hugetlb aware tasks. For example, in libhugetlbfs 2.14: mmap-gettest 10 32783 (2M: 64): <---- hit VM_BUG_ON_PAGE mmap-cow 32782 32783 (2M: 32): FAIL Failed to create shared mapping: Cannot allocate memory mmap-cow 32782 32783 (2M: 64): FAIL Failed to create shared mapping: Cannot allocate memory While I have not looked into why 'mmap-gettest' keeps failing, it is of no importance to this particular issue. This problem is similar to why we have the hugetlb_instantiation_mutex, hugepages are quite finite. Revert the use of VM_BUG_ON_PAGE back to just VM_BUG_ON.
VM_BUG_ON_PAGE is just a VM_BUG_ON that does dump_page before the BUG(). The only reason to use VM_BUG_ON instead of VM_BUG_ON_PAGE is if the page you're working with doesn't make sense/isn't useful as debug output. If doing a dump_page is causing issues somewhere then dump_pages should be fixed - instead of hiding the problem under the rug by not using it. Thanks, sasha -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>