From: Prakash Sangappa <email@example.com> To: Christoph Hellwig <firstname.lastname@example.org> Cc: Dave Hansen <email@example.com>, firstname.lastname@example.org, email@example.com, Andrea Arcangeli <firstname.lastname@example.org> Subject: Re: [PATCH RFC] hugetlbfs 'noautofill' mount option Date: Tue, 16 May 2017 09:51:40 -0700 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> On 5/9/17 1:59 PM, Prakash Sangappa wrote: > > > On 5/9/17 1:58 AM, Christoph Hellwig wrote: >> On Mon, May 08, 2017 at 03:12:42PM -0700, prakash.sangappa wrote: >>> Regarding #3 as a general feature, do we want to >>> consider this and the complexity associated with the >>> implementation? >> We have to. Given that no one has exclusive access to hugetlbfs >> a mount option is fundamentally the wrong interface. > > > A hugetlbfs filesystem may need to be mounted for exclusive use by > an application. Note, recently the 'min_size' mount option was added > to hugetlbfs, which would reserve minimum number of huge pages > for that filesystem for use by an application. If the filesystem with > min size specified, is not setup for exclusive use by an application, > then the purpose of reserving huge pages is defeated. The > min_size option was for use by applications like the database. > > Also, I am investigating enabling hugetlbfs mounts within user > namespace's mount namespace. That would allow an application > to mount a hugetlbfs filesystem inside a namespace exclusively for > its use, running as a non root user. For this it seems like the > 'min_size' > should be subject to some user limits. Anyways, mounting inside > user namespaces is a different discussion. > > So, if a filesystem has to be setup for exclusive use by an application, > then different mount options can be used for that filesystem. > Any further comments? Cc'ing Andrea as we had discussed this requirement for the Database.
next prev parent reply other threads:[~2017-05-16 16:52 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <email@example.com> 2017-05-01 18:00 ` Prakash Sangappa 2017-05-02 10:53 ` Anshuman Khandual 2017-05-02 16:07 ` Prakash Sangappa 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 [this message] 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.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).