From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751222AbdEBXnx (ORCPT ); Tue, 2 May 2017 19:43:53 -0400 Received: from mga06.intel.com ([134.134.136.31]:46879 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750912AbdEBXnv (ORCPT ); Tue, 2 May 2017 19:43:51 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.38,281,1491289200"; d="scan'208";a="963682859" 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> <7ff6fb32-7d16-af4f-d9d5-698ab7e9e14b@intel.com> <03127895-3c5a-5182-82de-3baa3116749e@oracle.com> From: Dave Hansen Message-ID: <22557bf3-14bb-de02-7b1b-a79873c583f1@intel.com> Date: Tue, 2 May 2017 16:43:50 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <03127895-3c5a-5182-82de-3baa3116749e@oracle.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.