From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S933162AbbCDMJ5 (ORCPT <rfc822;w@1wt.eu>);
	Wed, 4 Mar 2015 07:09:57 -0500
Received: from cantor2.suse.de ([195.135.220.15]:36633 "EHLO mx2.suse.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1757119AbbCDMJ4 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 4 Mar 2015 07:09:56 -0500
Message-ID: <54F6F60F.4070705@suse.cz>
Date: Wed, 04 Mar 2015 13:09:51 +0100
From: Vlastimil Babka <vbabka@suse.cz>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: "Kirill A. Shutemov" <kirill@shutemov.name>
CC: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Andrea Arcangeli <aarcange@redhat.com>,
        Hugh Dickins <hughd@google.com>, Dave Hansen <dave.hansen@intel.com>,
        Mel Gorman <mgorman@suse.de>, Rik van Riel <riel@redhat.com>,
        Christoph Lameter <cl@gentwo.org>,
        Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
        Steve Capper <steve.capper@linaro.org>,
        "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
        Johannes Weiner <hannes@cmpxchg.org>, Michal Hocko <mhocko@suse.cz>,
        Jerome Marchand <jmarchan@redhat.com>, linux-kernel@vger.kernel.org,
        linux-mm@kvack.org
Subject: Re: [PATCHv3 04/24] rmap: add argument to charge compound page
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>
In-Reply-To: <20150304115244.GA16452@node.dhcp.inet.fi>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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?