Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1634337

Re: [PATCH RFC] hugetlbfs 'noautofill' mount option

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

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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