From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Hansen Subject: Re: [PATCHv4 09/39] thp, mm: introduce mapping_can_have_hugepages() predicate Date: Wed, 22 May 2013 08:31:39 -0700 Message-ID: <519CE4DB.9070303@sr71.net> References: <1368321816-17719-1-git-send-email-kirill.shutemov@linux.intel.com> <1368321816-17719-10-git-send-email-kirill.shutemov@linux.intel.com> <519BCACD.4020106@sr71.net> <20130522135112.32C3EE0090@blue.fi.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Andrea Arcangeli , Andrew Morton , Al Viro , Hugh Dickins , Wu Fengguang , Jan Kara , Mel Gorman , linux-mm@kvack.org, Andi Kleen , Matthew Wilcox , "Kirill A. Shutemov" , Hillf Danton , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: "Kirill A. Shutemov" Return-path: In-Reply-To: <20130522135112.32C3EE0090@blue.fi.intel.com> Sender: owner-linux-mm@kvack.org List-Id: linux-fsdevel.vger.kernel.org On 05/22/2013 06:51 AM, Kirill A. Shutemov wrote: > Dave Hansen wrote: >> Also, what happens if "transparent_hugepage_flags & >> (1<> have some already-instantiated huge page cache mappings around? Will >> things like mapping_align_mask() break? > > We will not touch existing huge pages in existing VMAs. The userspace can > use them until they will be unmapped or split. It's consistent with anon > THP pages. > > If anybody mmap() the file after disabling the feature, we will not > setup huge pages anymore: transparent_hugepage_enabled() check in > handle_mm_fault will fail and the page fill be split. > > mapping_align_mask() is part of mmap() call path, so there's only chance > that we will get VMA aligned more strictly then needed. Nothing to worry > about. Could we get a little blurb along those lines somewhere? Maybe even in your docs that you've added to Documentation/. Oh, wait, you don't have any documentation? :) You did add a sysfs knob, so you do owe us some docs for it. "If the THP-cache sysfs tunable is disabled, huge pages will no longer be mapped with new mmap()s, but they will remain in place in the page cache. You might still see some benefits from read/write operations, etc..." -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756514Ab3EVPbm (ORCPT ); Wed, 22 May 2013 11:31:42 -0400 Received: from www.sr71.net ([198.145.64.142]:52755 "EHLO blackbird.sr71.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755409Ab3EVPbk (ORCPT ); Wed, 22 May 2013 11:31:40 -0400 Message-ID: <519CE4DB.9070303@sr71.net> Date: Wed, 22 May 2013 08:31:39 -0700 From: Dave Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Kirill A. Shutemov" CC: Andrea Arcangeli , Andrew Morton , Al Viro , Hugh Dickins , Wu Fengguang , Jan Kara , Mel Gorman , linux-mm@kvack.org, Andi Kleen , Matthew Wilcox , "Kirill A. Shutemov" , Hillf Danton , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCHv4 09/39] thp, mm: introduce mapping_can_have_hugepages() predicate References: <1368321816-17719-1-git-send-email-kirill.shutemov@linux.intel.com> <1368321816-17719-10-git-send-email-kirill.shutemov@linux.intel.com> <519BCACD.4020106@sr71.net> <20130522135112.32C3EE0090@blue.fi.intel.com> In-Reply-To: <20130522135112.32C3EE0090@blue.fi.intel.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/22/2013 06:51 AM, Kirill A. Shutemov wrote: > Dave Hansen wrote: >> Also, what happens if "transparent_hugepage_flags & >> (1<> have some already-instantiated huge page cache mappings around? Will >> things like mapping_align_mask() break? > > We will not touch existing huge pages in existing VMAs. The userspace can > use them until they will be unmapped or split. It's consistent with anon > THP pages. > > If anybody mmap() the file after disabling the feature, we will not > setup huge pages anymore: transparent_hugepage_enabled() check in > handle_mm_fault will fail and the page fill be split. > > mapping_align_mask() is part of mmap() call path, so there's only chance > that we will get VMA aligned more strictly then needed. Nothing to worry > about. Could we get a little blurb along those lines somewhere? Maybe even in your docs that you've added to Documentation/. Oh, wait, you don't have any documentation? :) You did add a sysfs knob, so you do owe us some docs for it. "If the THP-cache sysfs tunable is disabled, huge pages will no longer be mapped with new mmap()s, but they will remain in place in the page cache. You might still see some benefits from read/write operations, etc..."