From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756406AbbFBJdN (ORCPT ); Tue, 2 Jun 2015 05:33:13 -0400 Received: from cantor2.suse.de ([195.135.220.15]:54006 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753500AbbFBJdH (ORCPT ); Tue, 2 Jun 2015 05:33:07 -0400 Message-ID: <556D7851.1020107@suse.cz> Date: Tue, 02 Jun 2015 11:33:05 +0200 From: Vlastimil Babka User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Michal Hocko CC: Mel Gorman , Johannes Weiner , Andrew Morton , Naoya Horiguchi , linux-mm@kvack.org, LKML Subject: Re: [PATCH] hugetlb: Do not account hugetlb pages as NR_FILE_PAGES References: <1432214842-22730-1-git-send-email-mhocko@suse.cz> <20150521170909.GA12800@cmpxchg.org> <20150522142143.GF5109@dhcp22.suse.cz> <20150522143558.GA2462@suse.de> <55633EAC.8060702@suse.cz> <20150602092535.GB4440@dhcp22.suse.cz> In-Reply-To: <20150602092535.GB4440@dhcp22.suse.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/02/2015 11:25 AM, Michal Hocko wrote: > On Mon 25-05-15 17:24:28, Vlastimil Babka wrote: >> On 05/22/2015 04:35 PM, Mel Gorman wrote: >>>> >>>> Thanks! >>>> >>>>> This makes a lot of sense to me. The only thing I worry about is the >>>>> proliferation of PageHuge(), a function call, in relatively hot paths. >>>> >>>> I've tried that (see the patch below) but it enlarged the code by almost >>>> 1k >>>> text data bss dec hex filename >>>> 510323 74273 44440 629036 9992c mm/built-in.o.before >>>> 511248 74273 44440 629961 99cc9 mm/built-in.o.after >>>> >>>> I am not sure the code size increase is worth it. Maybe we can reduce >>>> the check to only PageCompound(page) as huge pages are no in the page >>>> cache (yet). >>>> >>> >>> That would be a more sensible route because it also avoids exposing the >>> hugetlbfs destructor unnecessarily. >> >> You could maybe do test such as (PageCompound(page) && PageHuge(page)) to >> short-circuit the call while remaining future-proof. > > How about this? Yeah (see below) > --- > diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h > index 91b7f9b2b774..bb8a70e8fc77 100644 > --- a/include/linux/page-flags.h > +++ b/include/linux/page-flags.h > @@ -547,7 +547,13 @@ static inline void ClearPageCompound(struct page *page) > #endif /* !PAGEFLAGS_EXTENDED */ > > #ifdef CONFIG_HUGETLB_PAGE > -int PageHuge(struct page *page); > +int __PageHuge(struct page *page); > +static inline int PageHuge(struct page *page) > +{ > + if (!PageCompound(page)) Perhaps the above as likely()? [...] > -EXPORT_SYMBOL_GPL(PageHuge); > +EXPORT_SYMBOL_GPL(__PageHuge); > > /* > * PageHeadHuge() only returns true for hugetlbfs head page, but not for > Do the same thing here by inlining the PageHead() test? I guess the page_to_pgoff and __compound_tail_refcounted callers are rather hot?