Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1634337
| From | Anshuman Khandual <khandual@linux.vnet.ibm.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH RFC] hugetlbfs 'noautofill' mount option |
| Date | 2017-05-02 13:00 +0200 |
| Message-ID | <tCDHb-5wb-1@gated-at.bofh.it> (permalink) |
| References | <tCnVL-417-9@gated-at.bofh.it> <tCnVL-417-7@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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 ?
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH RFC] hugetlbfs 'noautofill' mount option Prakash Sangappa <prakash.sangappa@oracle.com> - 2017-05-01 20:10 +0200
Re: [PATCH RFC] hugetlbfs 'noautofill' mount option Anshuman Khandual <khandual@linux.vnet.ibm.com> - 2017-05-02 13:00 +0200
Re: [PATCH RFC] hugetlbfs 'noautofill' mount option Prakash Sangappa <prakash.sangappa@oracle.com> - 2017-05-02 18:10 +0200
Re: [PATCH RFC] hugetlbfs 'noautofill' mount option Dave Hansen <dave.hansen@intel.com> - 2017-05-02 23:40 +0200
Re: [PATCH RFC] hugetlbfs 'noautofill' mount option Prakash Sangappa <prakash.sangappa@oracle.com> - 2017-05-03 01:40 +0200
Re: [PATCH RFC] hugetlbfs 'noautofill' mount option Dave Hansen <dave.hansen@intel.com> - 2017-05-03 01:50 +0200
Re: [PATCH RFC] hugetlbfs 'noautofill' mount option Prakash Sangappa <prakash.sangappa@oracle.com> - 2017-05-03 21:10 +0200
Re: [PATCH RFC] hugetlbfs 'noautofill' mount option Prakash Sangappa <prakash.sangappa@oracle.com> - 2017-05-08 08:00 +0200
Re: [PATCH RFC] hugetlbfs 'noautofill' mount option Dave Hansen <dave.hansen@intel.com> - 2017-05-08 18:00 +0200
Re: [PATCH RFC] hugetlbfs 'noautofill' mount option "prakash.sangappa" <prakash.sangappa@oracle.com> - 2017-05-09 00:20 +0200
Re: [PATCH RFC] hugetlbfs 'noautofill' mount option Christoph Hellwig <hch@infradead.org> - 2017-05-09 11:00 +0200
Re: [PATCH RFC] hugetlbfs 'noautofill' mount option Prakash Sangappa <prakash.sangappa@oracle.com> - 2017-05-09 23:10 +0200
csiph-web