On 05/01/2017 11:30 PM, Prakash Sangappa wrote:
Some applications like a database use hugetblfs for performances/mapped/unmapped/ ^ ?
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
Any access to mapped address over holes in the file, which can occur due
Sure, that is a valid behavior. However, hugetlbfs is a pesudo filesystem
to bugs in the application, is considered invalid and expect the processBut this is expected when you try to control the file allocation from
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
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 ?
The application would allocate/free file pages using the fallocate() API.in the file. This may not be the desired behavior for applications like theWhen the page should be allocated for mapping ?
database that want to explicitly manage page allocations of hugetlbfs
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