From: Prakash Sangappa <prakash.sangappa@oracle.com> To: Anshuman Khandual <khandual@linux.vnet.ibm.com>, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH RFC] hugetlbfs 'noautofill' mount option Date: Tue, 2 May 2017 09:07:00 -0700 [thread overview] Message-ID: <07f3fde3-b296-f205-377d-1b4c3bbedb70@oracle.com> (raw) In-Reply-To: <06c4eb97-1545-7958-7694-3645d317666b@linux.vnet.ibm.com> On 5/2/17 3:53 AM, Anshuman Khandual wrote: > 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/ ^ ? It is 'mapped' address. > >> 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 ? Sure, that is a valid behavior. However, hugetlbfs is a pesudo filesystem and the purpose is for applications to use hugepage memory. The contents of these filesystem are not backed by disk nor are they swapped out. The proposed new behavior is only applicable for hugetlbfs filesystem mounted with the new 'noautofill' mount option. The file's page allocation/free are managed using the 'fallocate()' API. For hugetlbfs filesystems mounted without this option, there is no change in 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 ? The application would allocate/free file pages using the fallocate() API.
next prev parent reply other threads:[~2017-05-02 16:07 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <326e38dd-b4a8-e0ca-6ff7-af60e8045c74@oracle.com> 2017-05-01 18:00 ` Prakash Sangappa 2017-05-02 10:53 ` Anshuman Khandual 2017-05-02 16:07 ` Prakash Sangappa [this message] 2017-05-02 21:32 ` Dave Hansen 2017-05-02 23:34 ` Prakash Sangappa 2017-05-02 23:43 ` Dave Hansen 2017-05-03 19:02 ` Prakash Sangappa 2017-05-08 5:57 ` Prakash Sangappa 2017-05-08 15:58 ` Dave Hansen 2017-05-08 22:12 ` prakash.sangappa 2017-05-09 8:58 ` Christoph Hellwig 2017-05-09 20:59 ` Prakash Sangappa 2017-05-16 16:51 ` Prakash Sangappa 2017-06-16 13:15 ` Andrea Arcangeli 2017-06-20 23:35 ` Prakash Sangappa 2017-06-27 20:57 ` Prakash Sangappa
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=07f3fde3-b296-f205-377d-1b4c3bbedb70@oracle.com \ --to=prakash.sangappa@oracle.com \ --cc=khandual@linux.vnet.ibm.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --subject='Re: [PATCH RFC] hugetlbfs '\''noautofill'\'' mount option' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).