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: Tue, 21 May 2013 12:28:13 -0700 Message-ID: <519BCACD.4020106@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> 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: <1368321816-17719-10-git-send-email-kirill.shutemov@linux.intel.com> Sender: owner-linux-mm@kvack.org List-Id: linux-fsdevel.vger.kernel.org On 05/11/2013 06:23 PM, Kirill A. Shutemov wrote: > From: "Kirill A. Shutemov" > > Returns true if mapping can have huge pages. Just check for __GFP_COMP > in gfp mask of the mapping for now. > > Signed-off-by: Kirill A. Shutemov > --- > include/linux/pagemap.h | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h > index e3dea75..28597ec 100644 > --- a/include/linux/pagemap.h > +++ b/include/linux/pagemap.h > @@ -84,6 +84,18 @@ static inline void mapping_set_gfp_mask(struct address_space *m, gfp_t mask) > (__force unsigned long)mask; > } > > +static inline bool mapping_can_have_hugepages(struct address_space *m) > +{ > + if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE_PAGECACHE)) { > + gfp_t gfp_mask = mapping_gfp_mask(m); > + /* __GFP_COMP is key part of GFP_TRANSHUGE */ > + return !!(gfp_mask & __GFP_COMP) && > + transparent_hugepage_pagecache(); > + } > + > + return false; > +} transparent_hugepage_pagecache() already has the same IS_ENABLED() check, Is it really necessary to do it again here? IOW, can you do this? > +static inline bool mapping_can_have_hugepages(struct address_space > +{ > + gfp_t gfp_mask = mapping_gfp_mask(m); if (!transparent_hugepage_pagecache()) return false; > + /* __GFP_COMP is key part of GFP_TRANSHUGE */ > + return !!(gfp_mask & __GFP_COMP); > +} I know we talked about this in the past, but I've forgotten already. Why is this checking for __GFP_COMP instead of GFP_TRANSHUGE? Please flesh out the comment. Also, what happens if "transparent_hugepage_flags & (1< 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 S1755678Ab3EUT2T (ORCPT ); Tue, 21 May 2013 15:28:19 -0400 Received: from www.sr71.net ([198.145.64.142]:44396 "EHLO blackbird.sr71.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753019Ab3EUT2Q (ORCPT ); Tue, 21 May 2013 15:28:16 -0400 Message-ID: <519BCACD.4020106@sr71.net> Date: Tue, 21 May 2013 12:28:13 -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> In-Reply-To: <1368321816-17719-10-git-send-email-kirill.shutemov@linux.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/11/2013 06:23 PM, Kirill A. Shutemov wrote: > From: "Kirill A. Shutemov" > > Returns true if mapping can have huge pages. Just check for __GFP_COMP > in gfp mask of the mapping for now. > > Signed-off-by: Kirill A. Shutemov > --- > include/linux/pagemap.h | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h > index e3dea75..28597ec 100644 > --- a/include/linux/pagemap.h > +++ b/include/linux/pagemap.h > @@ -84,6 +84,18 @@ static inline void mapping_set_gfp_mask(struct address_space *m, gfp_t mask) > (__force unsigned long)mask; > } > > +static inline bool mapping_can_have_hugepages(struct address_space *m) > +{ > + if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE_PAGECACHE)) { > + gfp_t gfp_mask = mapping_gfp_mask(m); > + /* __GFP_COMP is key part of GFP_TRANSHUGE */ > + return !!(gfp_mask & __GFP_COMP) && > + transparent_hugepage_pagecache(); > + } > + > + return false; > +} transparent_hugepage_pagecache() already has the same IS_ENABLED() check, Is it really necessary to do it again here? IOW, can you do this? > +static inline bool mapping_can_have_hugepages(struct address_space > +{ > + gfp_t gfp_mask = mapping_gfp_mask(m); if (!transparent_hugepage_pagecache()) return false; > + /* __GFP_COMP is key part of GFP_TRANSHUGE */ > + return !!(gfp_mask & __GFP_COMP); > +} I know we talked about this in the past, but I've forgotten already. Why is this checking for __GFP_COMP instead of GFP_TRANSHUGE? Please flesh out the comment. Also, what happens if "transparent_hugepage_flags & (1<