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

From	Dave Hansen <dave.hansen@intel.com>
Newsgroups	linux.kernel
Subject	Re: [PATCH RFC] hugetlbfs 'noautofill' mount option
Date	2017-05-03 01:50 +0200
Message-ID	<tCPIm-4Ud-15@gated-at.bofh.it> (permalink)
References	<tCnVL-417-9@gated-at.bofh.it> <tCnVL-417-7@gated-at.bofh.it> <tCNGy-3EW-19@gated-at.bofh.it> <tCPyG-4R1-5@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On 05/02/2017 04:34 PM, Prakash Sangappa wrote:
> Similarly, a madvise() option also requires additional system call by every
> process mapping the file, this is considered a overhead for the database.

How long-lived are these processes?  For a database, I'd assume that
this would happen a single time, or a single time per mmap() at process
startup time.  Such a syscall would be doing something on the order of
taking mmap_sem, walking the VMA tree, setting a bit per VMA, and
unlocking.  That's a pretty cheap one-time cost...

> If we do consider a new madvise() option, will it be acceptable
> since this will be specifically for hugetlbfs file mappings?

Ideally, it would be something that is *not* specifically for hugetlbfs.
 MADV_NOAUTOFILL, for instance, could be defined to SIGSEGV whenever
memory is touched that was not populated with MADV_WILLNEED, mlock(), etc...

> If so,
> would a new flag to mmap() call itself be acceptable, which would
> define the proposed behavior?. That way no additional system calls
> need to be made.

I don't feel super strongly about it, but I guess an mmap() flag could
work too.

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