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 S1754176AbcHVLgb (ORCPT <rfc822;w@1wt.eu>);
        Mon, 22 Aug 2016 07:36:31 -0400
Received: from szxga01-in.huawei.com ([58.251.152.64]:2108 "EHLO
        szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751688AbcHVLga (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 22 Aug 2016 07:36:30 -0400
Subject: Re: [RFC PATCH v2 2/2] arm64 Kconfig: Select gigantic page
To: Catalin Marinas <catalin.marinas@arm.com>,
        Michal Hocko <mhocko@kernel.org>
References: <1471834603-27053-1-git-send-email-xieyisheng1@huawei.com>
 <1471834603-27053-3-git-send-email-xieyisheng1@huawei.com>
 <20160822080358.GF13596@dhcp22.suse.cz>
 <20160822100045.GA26494@e104818-lin.cambridge.arm.com>
CC: <mark.rutland@arm.com>, <linux-mm@kvack.org>, <sudeep.holla@arm.com>,
        <will.deacon@arm.com>, <linux-kernel@vger.kernel.org>,
        <dave.hansen@intel.com>, <robh+dt@kernel.org>, <guohanjun@huawei.com>,
        <akpm@linux-foundation.org>, <n-horiguchi@ah.jp.nec.com>,
        <linux-arm-kernel@lists.infradead.org>, <mike.kravetz@oracle.com>
From: Yisheng Xie <xieyisheng1@huawei.com>
Message-ID: <b5f1f756-4698-4c32-1c30-97b1ccf2b4a6@huawei.com>
Date: Mon, 22 Aug 2016 19:33:46 +0800
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <20160822100045.GA26494@e104818-lin.cambridge.arm.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.177.32.149]
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
        refid=str=0001.0A020203.57BAE32B.02A1,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0,
        ip=0.0.0.0,
        so=2013-06-18 04:22:30,
        dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 2acd2d44d89fc632cf810bbe068f0dc2
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org



On 2016/8/22 18:00, Catalin Marinas wrote:
> On Mon, Aug 22, 2016 at 10:03:58AM +0200, Michal Hocko wrote:
>> On Mon 22-08-16 10:56:43, Xie Yisheng wrote:
>>> Arm64 supports gigantic page after
>>> commit 084bd29810a5 ("ARM64: mm: HugeTLB support.")
>>> however, it got broken by 
>>> commit 944d9fec8d7a ("hugetlb: add support for gigantic page
>>> allocation at runtime")
>>>
>>> This patch selects ARCH_HAS_GIGANTIC_PAGE to make this
>>> function can be used again.
>>
>> I haven't double checked that the above commit really broke it but if
>> that is the case then
>>  
>> Fixes: 944d9fec8d7a ("hugetlb: add support for gigantic page allocation at runtime")
>>
>> would be nice as well I guess. I do not think that marking it for stable
>> is really necessary considering how long it's been broken and nobody has
>> noticed...
> 
> I'm not sure that commit broke it. The gigantic functionality introduced
> by the above commit was under an #ifdef CONFIG_X86_64. Prior
> to that we had a VM_BUG_ON(hstate_is_gigantic(h)).
> 
Hi Catalin and Michal ,
Thank you for your reply.
Before that commit gigantic pages can only be allocated at boottime and
can't be freed. That why we had VM_BUG_ON(hstate_is_gigantic(h)) in
function update_and_free_page() Prior to that.

Anyway, it should not just add #ifdef CONFIG_X86_64 for arm64 already
supported 1G hugepage before that commit. Right?

Please let me know if I miss something.

Thanks
Xie Yisheng.