From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751363AbdEBKyr (ORCPT ); Tue, 2 May 2017 06:54:47 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:57199 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750912AbdEBKyp (ORCPT ); Tue, 2 May 2017 06:54:45 -0400 Subject: Re: [PATCH RFC] hugetlbfs 'noautofill' mount option To: Prakash Sangappa , linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <326e38dd-b4a8-e0ca-6ff7-af60e8045c74@oracle.com> From: Anshuman Khandual Date: Tue, 2 May 2017 16:23:48 +0530 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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable x-cbid: 17050210-1617-0000-0000-000001C8AB83 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17050210-1618-0000-0000-000048095CD7 Message-Id: <06c4eb97-1545-7958-7694-3645d317666b@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-02_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705020064 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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/ ^ ? > 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 ? > 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 ?