From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752482AbdEHWL0 (ORCPT ); Mon, 8 May 2017 18:11:26 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:16390 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750794AbdEHWLZ (ORCPT ); Mon, 8 May 2017 18:11:25 -0400 Reply-To: prakash.sangappa@oracle.com Subject: Re: [PATCH RFC] hugetlbfs 'noautofill' mount option 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> To: Dave Hansen , linux-kernel@vger.kernel.org, linux-mm@kvack.org From: "prakash.sangappa" Message-ID: <476ea1b6-36d1-bc86-fa99-b727e3c2650d@oracle.com> Date: Mon, 8 May 2017 15:12:42 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <48a544c4-61b3-acaf-0386-649f073602b6@intel.com> Content-Type: text/plain; charset=utf-8; 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 05/08/2017 08:58 AM, Dave Hansen wrote: > > It depends on how you define the feature. I think you have three choices: > > 1. "Error" on page fault. Require all access to be pre-faulted. > 2. Allow faults, but "Error" if page cache has to be allocated > 3. Allow faults and page cache allocations, but error on filesystem > backing storage allocation. > > All of those are useful in some cases. But the implementations probably > happen in different places: > > #1 can be implemented in core mm code > #2 can be implemented in the VFS > #3 needs filesystem involvement Sure it will depend on how we define the feature. However, I am not clear about how useful are #1 & #2 as a general feature with respect to filesystems, but I assume we could find some use cases for them. Regarding #3 as a general feature, do we want to consider this and the complexity associated with the implementation? > >> In case of hugetlbfs it is much straight forward. Since this >> filesystem is not like a normal filesystems and and the file sizes >> are multiple of huge pages. The hole will be a multiple of the huge >> page size. For this reason then should the advise be specific to >> hugetlbfs? > Let me paraphrase: it's simpler to implement it if it's specific to > hugetlbfs, thus we should implement it only for hugetlbfs, and keep it > specific to hugetlbfs. > > The bigger question is: do we want to continue adding to the complexity > of hugetlbfs and increase its divergence from the core mm? Ok, The purpose of hugetlbfs is to enable applications to be able to use memory in huge page sizes. Expecting that there will be no change to its purpose other then this. The filesystem API fallocate(), with the recent addition for hole punching support to free pages, allows explicit control on page allocation / deallocation which is useful. It seems that the 'noautofill' feature is what is missing, with regards to applications having explicit control on memory page allocations using hugetlbfs. Even though the description for this feature is not to fill holes in files, given it is filesystem semantic, but actually the intent is to indicate not allocating pages implicitly as the application is primarily dealing with memory allocation and deallocation here. Is this a good enough justification?