From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754451AbbCDN0n (ORCPT ); Wed, 4 Mar 2015 08:26:43 -0500 Received: from mta-out1.inet.fi ([62.71.2.203]:50513 "EHLO jenni2.inet.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751830AbbCDN0l (ORCPT ); Wed, 4 Mar 2015 08:26:41 -0500 Date: Wed, 4 Mar 2015 15:26:17 +0200 From: "Kirill A. Shutemov" To: Vlastimil Babka Cc: "Kirill A. Shutemov" , Andrew Morton , Andrea Arcangeli , Hugh Dickins , Dave Hansen , Mel Gorman , Rik van Riel , Christoph Lameter , Naoya Horiguchi , Steve Capper , "Aneesh Kumar K.V" , Johannes Weiner , Michal Hocko , Jerome Marchand , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCHv3 04/24] rmap: add argument to charge compound page Message-ID: <20150304132617.GB16452@node.dhcp.inet.fi> References: <1423757918-197669-1-git-send-email-kirill.shutemov@linux.intel.com> <1423757918-197669-5-git-send-email-kirill.shutemov@linux.intel.com> <54EB538B.7040308@suse.cz> <20150304115244.GA16452@node.dhcp.inet.fi> <54F6F60F.4070705@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54F6F60F.4070705@suse.cz> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 04, 2015 at 01:09:51PM +0100, Vlastimil Babka wrote: > On 03/04/2015 12:52 PM, Kirill A. Shutemov wrote: > >On Mon, Feb 23, 2015 at 05:21:31PM +0100, Vlastimil Babka wrote: > >>On 02/12/2015 05:18 PM, Kirill A. Shutemov wrote: > >>>@@ -1052,21 +1052,24 @@ void page_add_anon_rmap(struct page *page, > >>> * Everybody else should continue to use page_add_anon_rmap above. > >>> */ > >>> void do_page_add_anon_rmap(struct page *page, > >>>- struct vm_area_struct *vma, unsigned long address, int exclusive) > >>>+ struct vm_area_struct *vma, unsigned long address, int flags) > >>> { > >>> int first = atomic_inc_and_test(&page->_mapcount); > >>> if (first) { > >>>+ bool compound = flags & RMAP_COMPOUND; > >>>+ int nr = compound ? hpage_nr_pages(page) : 1; > >> > >>hpage_nr_pages(page) is: > >> > >>static inline int hpage_nr_pages(struct page *page) > >>{ > >> if (unlikely(PageTransHuge(page))) > >> return HPAGE_PMD_NR; > >> return 1; > >>} > >> > >>and later... > >> > >>> /* > >>> * We use the irq-unsafe __{inc|mod}_zone_page_stat because > >>> * these counters are not modified in interrupt context, and > >>> * pte lock(a spinlock) is held, which implies preemption > >>> * disabled. > >>> */ > >>>- if (PageTransHuge(page)) > >>>+ if (compound) { > >>>+ VM_BUG_ON_PAGE(!PageTransHuge(page), page); > >> > >>this means that we could assume that > >>(compound == true) => (PageTransHuge(page) == true) > >> > >>and simplify above to: > >> > >>int nr = compound ? HPAGE_PMD_NR : 1; > >> > >>Right? > > > >No. HPAGE_PMD_NR is defined based on HPAGE_PMD_SHIFT which is BUILD_BUG() > >without CONFIG_TRANSPARENT_HUGEPAGE. We will get compiler error without > >the helper. > > Oh, OK. But that doesn't mean there couldn't be another helper that would > work in this case, or even open-coded #ifdefs in these functions. Apparently > "compound" has to be always false for !CONFIG_TRANSPARENT_HUGEPAGE, as in > that case PageTransHuge is defined as 0 and the VM_BUG_ON would trigger if > compound was true. So without such ifdefs or wrappers, you are also adding > dead code and pointless tests for !CONFIG_TRANSPARENT_HUGEPAGE? Yeah, this definitely can be improved. I prefer to do it as follow up. I want to get stable what I have now. -- Kirill A. Shutemov