From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753321AbdEPQwc (ORCPT ); Tue, 16 May 2017 12:52:32 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:32646 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750795AbdEPQw2 (ORCPT ); Tue, 16 May 2017 12:52:28 -0400 Subject: Re: [PATCH RFC] hugetlbfs 'noautofill' mount option To: Christoph Hellwig References: <326e38dd-b4a8-e0ca-6ff7-af60e8045c74@oracle.com> <7ff6fb32-7d16-af4f-d9d5-698ab7e9e14b@intel.com> <03127895-3c5a-5182-82de-3baa3116749e@oracle.com> <22557bf3-14bb-de02-7b1b-a79873c583f1@intel.com> <7677d20e-5d53-1fb7-5dac-425edda70b7b@oracle.com> <48a544c4-61b3-acaf-0386-649f073602b6@intel.com> <476ea1b6-36d1-bc86-fa99-b727e3c2650d@oracle.com> <20170509085825.GB32555@infradead.org> <1031e0d4-cdbb-db8b-dae7-7c733921e20e@oracle.com> Cc: Dave Hansen , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrea Arcangeli From: Prakash Sangappa Message-ID: Date: Tue, 16 May 2017 09:51:40 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1031e0d4-cdbb-db8b-dae7-7c733921e20e@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: aserv0022.oracle.com [141.146.126.234] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.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.