On 05/01/2017 11:30 PM, Prakash Sangappa wrote: > Some applications like a database use hugetblfs for performance > reasons. Files on hugetlbfs filesystem are created and huge pages > allocated using fallocate() API. Pages are deallocated/freed using > fallocate() hole punching support that has been added to hugetlbfs. > These files are mmapped and accessed by many processes as shared memory. > Such applications keep track of which offsets in the hugetlbfs file have > pages allocated. > > Any access to mapped address over holes in the file, which can occur due s/mapped/unmapped/ ^ ? > to bugs in the application, is considered invalid and expect the process > to simply receive a SIGBUS. However, currently when a hole in the file is > accessed via the mapped address, kernel/mm attempts to automatically > allocate a page at page fault time, resulting in implicitly filling the > hole But this is expected when you try to control the file allocation from a mapped address. Any changes while walking past or writing the range in the memory mapped should reflect exactly in the file on the disk. Why its not a valid behavior ? > in the file. This may not be the desired behavior for applications like the > database that want to explicitly manage page allocations of hugetlbfs > files. > > This patch adds a new hugetlbfs mount option 'noautofill', to indicate that > pages should not be allocated at page fault time when accessed thru mmapped > address. When the page should be allocated for mapping ? -- 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>
