From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8C03BC433E0 for ; Fri, 12 Mar 2021 02:52:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 094E264F8E for ; Fri, 12 Mar 2021 02:52:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 094E264F8E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 364EF8D0321; Thu, 11 Mar 2021 21:52:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3153A8D0317; Thu, 11 Mar 2021 21:52:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1DDD58D0321; Thu, 11 Mar 2021 21:52:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0075.hostedemail.com [216.40.44.75]) by kanga.kvack.org (Postfix) with ESMTP id ED77C8D0317 for ; Thu, 11 Mar 2021 21:52:11 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 9FA03180B5F92 for ; Fri, 12 Mar 2021 02:52:11 +0000 (UTC) X-FDA: 77909698062.10.35130E8 Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) by imf09.hostedemail.com (Postfix) with ESMTP id 2D9496000102 for ; Fri, 12 Mar 2021 02:52:08 +0000 (UTC) Received: from DGGEMS405-HUB.china.huawei.com (unknown [172.30.72.60]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4DxVf52cytzmVjv; Fri, 12 Mar 2021 10:49:49 +0800 (CST) Received: from [10.174.177.134] (10.174.177.134) by DGGEMS405-HUB.china.huawei.com (10.3.19.205) with Microsoft SMTP Server id 14.3.498.0; Fri, 12 Mar 2021 10:52:01 +0800 Subject: Re: [PATCH 0/3] Add support for free vmemmap pages of HugeTLB for arm64 To: "Bodeddula, Balasubramaniam" , Muchun Song , "will@kernel.org" , "akpm@linux-foundation.org" , "david@redhat.com" , "osalvador@suse.de" , "mike.kravetz@oracle.com" , "rientjes@google.com" CC: "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "duanxiongchun@bytedance.com" , "Umesh Sargur, Gautam" References: <20210310071535.35245-1-songmuchun@bytedance.com> <3eae8b3e-d6e0-83c8-e9c6-5420767788d5@huawei.com> From: Chen Huang Message-ID: Date: Fri, 12 Mar 2021 10:52:00 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" X-Originating-IP: [10.174.177.134] X-CFilter-Loop: Reflected X-Stat-Signature: mafky1yxqf98ripcn4cybb11h6fqkmd9 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 2D9496000102 Received-SPF: none (huawei.com>: No applicable sender policy available) receiver=imf09; identity=mailfrom; envelope-from=""; helo=szxga04-in.huawei.com; client-ip=45.249.212.190 X-HE-DKIM-Result: none/none X-HE-Tag: 1615517528-734049 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Are you saying that the patch works well in x86, but doesn't in arm64? If= so, my suggestion is that first you can check the dumpstack to check whe= ther the function free_vmemmap_page has been called. Then you can dump the page list of vmemmap_pages and the refcount of page= s to verify the pages has been freed into the buddy system. Hope this will help you! =E5=9C=A8 2021/3/12 2:00, Bodeddula, Balasubramaniam =E5=86=99=E9=81=93: > Hey, thanks for the testing steps. >=20 > I tried applying these patches on 5.11 source tree. These patches were = applied on top of the x86 patch, which worked fine. But in this case we d= on't see the same improvements in our testing. We made sure we set CONFIG= _HUGETLB_PAGE_FREE_VMEMMAP=3Dy in our .config file. >=20 > Are we missing any more configuration settings to get this patch to wor= k on ARM? Can you please help with general troubleshooting steps to debug= what could be going wrong. >=20 > =EF=BB=BFOn 11/03/21, 11:32 AM, "Chen Huang" wr= ote: >=20 > CAUTION: This email originated from outside of the organization. Do= not click links or open attachments unless you can confirm the sender an= d know the content is safe. >=20 >=20 >=20 > =E5=9C=A8 2021/3/11 13:00, Bodeddula, Balasubramaniam =E5=86=99=E9=81= =93: > > Chen, is your testing steps documented somewhere, can you please = point us to the same. I followed some steps for testing the x86 patches, = just wanted to make sure I am covering your tests as well. We are activel= y working on building and testing these patches for ARM. > > > > On 11/03/21, 9:44 AM, "Chen Huang" wrote: > > > > CAUTION: This email originated from outside of the organizati= on. Do not click links or open attachments unless you can confirm the sen= der and know the content is safe. > > > > > > > > =E5=9C=A8 2021/3/10 15:15, Muchun Song =E5=86=99=E9=81=93: > > > This patchset is based on the series of "Free some vmemmap = pages of HugeTLB > > > page". More details can refer to the below link. > > > > > > https://lkml.kernel.org/r/20210308102807.59745-1-songmuch= un@bytedance.com > > > > > > I often received some feedback (We want to test this featur= e on arm64) before. > > > Because the previous code has been reviewed for 18 versions= and is merged > > > into mm tree, I think that it is time to release this patch= set. If you want > > > to test then you can start now :-). And I also hope someone= can review this. > > > > > > Thanks. > > > > > > Muchun Song (3): > > > mm: bootmem_info: mark register_page_bootmem_info_section= __init > > > mm: hugetlb: introduce arch_free_vmemmap_page > > > arm64: mm: hugetlb: add support for free vmemmap pages of= HugeTLB > > > > > > arch/arm64/mm/mmu.c | 5 +++++ > > > arch/x86/mm/init_64.c | 5 +++++ > > > fs/Kconfig | 4 ++-- > > > mm/bootmem_info.c | 4 ++-- > > > mm/sparse-vmemmap.c | 9 +++++++-- > > > 5 files changed, 21 insertions(+), 6 deletions(-) > > > > > > > Tested-by: Chen Huang > > > > I have tested the patch and the result is same as the last ti= me. > > >=20 > The test work is that: I set the total memory of 40G, and use 10G f= or hugepages. > First I reserve 10G hugepages from the command line and the result = is that: > -------------------------------------------------------------------= ----------------------------- > 2M page | = 1G page | > ----------------------|------------------------|-------------------= ---|------------------------| > enable | disable | enable = | disable | > ----------------------|------------------------|-------------------= ---|------------------------| > total | used | free | total | used | free |total | used | fr= ee | total | used | free | > 39,697 | 10279 |29,415| 39580 | 10279 | 29,297=E2=80=AC|39,739 | 1= 0279 |29,455| 39580 | 10279 | 29,296| > -------------------------------------------------------------------= ----------------------------- > For 2M hugepage, we can save 118M memory which is correspoinding to= the expected 120M memory. > For 1G hugepage, we can save 159M memory which is correspoinding to= the expected 160M memory. >=20 > Then I alloc 10G hugepages using "echo XX > /sys/kernel/mm/hugepage= s/hugepages-XXkB/nr_hugepages", > and get the result: > -------------------------------------------------------------------= ----------------------------- > 2M page | = 1G page | > ----------------------|------------------------|-------------------= ---|------------------------| > enable | disable | enable = | disable | > ----------------------|------------------------|-------------------= ---|------------------------| > total | used | free | total | used | free |total | used | fr= ee | total | used | free | > 39,699 | 10279 |29,415| 39580 | 10279 | 29,297=E2=80=AC=E2=80=AC|3= 9,739 | 10279 |29,455| 39580 | 10279 | 29,296| > -------------------------------------------------------------------= ----------------------------- > For 2M hugepage, we can save 118M memory which is correspoinding to= the expected 120M memory. > For 1G hugepage, we can save 159M memory which is correspoinding to= the expected 160M memory. >=20