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=-13.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 06EF8C433E0 for ; Thu, 11 Mar 2021 08:46:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7B63964FA9 for ; Thu, 11 Mar 2021 08:46:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7B63964FA9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=bytedance.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E19B88D0294; Thu, 11 Mar 2021 03:46:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DF0278D028E; Thu, 11 Mar 2021 03:46:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C91E88D0294; Thu, 11 Mar 2021 03:46:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id ADA858D028E for ; Thu, 11 Mar 2021 03:46:30 -0500 (EST) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 79BF64DC4 for ; Thu, 11 Mar 2021 08:46:30 +0000 (UTC) X-FDA: 77906962140.09.1D22F9B Received: from mail-pg1-f180.google.com (mail-pg1-f180.google.com [209.85.215.180]) by imf01.hostedemail.com (Postfix) with ESMTP id 07DAF2000381 for ; Thu, 11 Mar 2021 08:46:29 +0000 (UTC) Received: by mail-pg1-f180.google.com with SMTP id x29so13242734pgk.6 for ; Thu, 11 Mar 2021 00:46:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cQx/Zk70+m6LOsndOKLwPgVvEXoFZWWNDN7Tc+66h78=; b=d5ZOzK0nHfiuWFgsYpozB26n2SNLgu+yC+cyMbLJskAa4uat6g2X7ZqzHq3MPzJkqT e2EeCNXm48n2JGpBerR8kVEVlvjHVLj2cIpMFh2z9BIC+yQpRZzFcWfa5p5RF+Coj8z3 AdKrqpImJC5chGGGPbL0t4QjWFC13Y27lJvZ3x107SX7Uq6cE7Ao0/WkX5EjePrutbnD HRvbrEiVa5H4a2RLFhQ0SPgGj02m2BvYCSW1GdfChG78rbnzWdwpmOpUbjQMvbja7gTy NNTD6eQ6jEKoYCjDzGXv3JAQas4n8S7WxpjA5BPhKvy4EUFsH6oCrU4VsIfvVty8/8wt M43g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cQx/Zk70+m6LOsndOKLwPgVvEXoFZWWNDN7Tc+66h78=; b=h+WZJ92JRaCzXIRIvpkJGG419wlW3wsr3uIzTrOGKsaGag9hcwFtw/nWurcAnRNFVc PNaRJ7jHc1LrSW9DBT1Er53KATRwzwc9t5CVc40Gj8O/SBXYEnEPchn8ZeEM3wQFlpOy DaZJWq4JisKH+zQBct2zXhz5TGr52FnlSfLB/EC5dvhrTNpaaJa2oEcFVQALyEUsftfC 1CTHCf5pw+SF8FO/6MgGfxKWOnRqybBzTrAxeHAxsav/bmc2EUdCxeN3oS6NcHlFk5XL wyN3g3abiP0COLYYpGycXHO/hcWm/wYmryfA3mn0DCZWPlrxe1F7DLTSQkLECcHQGc+A I6LA== X-Gm-Message-State: AOAM531tGZWghEM0UhC/r16jIhf9J5XUh0sMV4r0c8Nds4MQS1kV2WXQ s3wrrmn516X3e65VKlgULfeg/WrfIVD1RcFGzqzVEA== X-Google-Smtp-Source: ABdhPJx8xoUZld8Sv1xB5EcygOS8Cx3xevOUQo1rIS2UOdYOWKLXng+0qazdq2+zuAO7Wv4IQBY5jVo18AZxOgHgpOo= X-Received: by 2002:aa7:9614:0:b029:1fa:e77b:722 with SMTP id q20-20020aa796140000b02901fae77b0722mr6837612pfg.2.1615452388283; Thu, 11 Mar 2021 00:46:28 -0800 (PST) MIME-Version: 1.0 References: <20210308102807.59745-1-songmuchun@bytedance.com> <20210308102807.59745-2-songmuchun@bytedance.com> In-Reply-To: From: Muchun Song Date: Thu, 11 Mar 2021 16:45:51 +0800 Message-ID: Subject: Re: [External] Re: [PATCH v18 1/9] mm: memory_hotplug: factor out bootmem core functions to bootmem_info.c To: Michal Hocko Cc: Jonathan Corbet , Mike Kravetz , Thomas Gleixner , Ingo Molnar , bp@alien8.de, x86@kernel.org, hpa@zytor.com, dave.hansen@linux.intel.com, luto@kernel.org, Peter Zijlstra , Alexander Viro , Andrew Morton , paulmck@kernel.org, mchehab+huawei@kernel.org, pawan.kumar.gupta@linux.intel.com, Randy Dunlap , oneukum@suse.com, anshuman.khandual@arm.com, jroedel@suse.de, Mina Almasry , David Rientjes , Matthew Wilcox , Oscar Salvador , "Song Bao Hua (Barry Song)" , David Hildenbrand , =?UTF-8?B?SE9SSUdVQ0hJIE5BT1lBKOWggOWPoyDnm7TkuZ8p?= , Joao Martins , Xiongchun duan , linux-doc@vger.kernel.org, LKML , Linux Memory Management List , linux-fsdevel , Miaohe Lin , Chen Huang , Bodeddula Balasubramaniam Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: i7ho4grugo9eccmjaqqybs7nupw9frm1 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 07DAF2000381 Received-SPF: none (bytedance.com>: No applicable sender policy available) receiver=imf01; identity=mailfrom; envelope-from=""; helo=mail-pg1-f180.google.com; client-ip=209.85.215.180 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1615452389-173478 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: On Thu, Mar 11, 2021 at 10:58 AM Muchun Song wrote: > > On Wed, Mar 10, 2021 at 10:14 PM Michal Hocko wrote: > > > > [I am sorry for a late review] > > Thanks for your review. > > > > > On Mon 08-03-21 18:27:59, Muchun Song wrote: > > > Move bootmem info registration common API to individual bootmem_info.c. > > > And we will use {get,put}_page_bootmem() to initialize the page for the > > > vmemmap pages or free the vmemmap pages to buddy in the later patch. > > > So move them out of CONFIG_MEMORY_HOTPLUG_SPARSE. This is just code > > > movement without any functional change. > > > > > > Signed-off-by: Muchun Song > > > Acked-by: Mike Kravetz > > > Reviewed-by: Oscar Salvador > > > Reviewed-by: David Hildenbrand > > > Reviewed-by: Miaohe Lin > > > Tested-by: Chen Huang > > > Tested-by: Bodeddula Balasubramaniam > > > > Separation from memory_hotplug.c is definitely a right step. I am > > wondering about the config dependency though > > [...] > > > diff --git a/mm/Makefile b/mm/Makefile > > > index 72227b24a616..daabf86d7da8 100644 > > > --- a/mm/Makefile > > > +++ b/mm/Makefile > > > @@ -83,6 +83,7 @@ obj-$(CONFIG_SLUB) += slub.o > > > obj-$(CONFIG_KASAN) += kasan/ > > > obj-$(CONFIG_KFENCE) += kfence/ > > > obj-$(CONFIG_FAILSLAB) += failslab.o > > > +obj-$(CONFIG_HAVE_BOOTMEM_INFO_NODE) += bootmem_info.o > > > > I would have expected this would depend on CONFIG_SPARSE. > > BOOTMEM_INFO_NODE is really an odd thing to depend on here. There is > > some functionality which requires the node info but that can be gated > > specifically. Or what is the thinking behind? I have tried this. And I find that it is better to depend on BOOTMEM_INFO_NODE instead of SPARSEMEM. If we enable SPARSEMEM but disable HAVE_BOOTMEM_INFO_NODE, the bootmem_info.c also is compiled. Actually, we do not need those functions on other architectures. And these functions are also related to bootmem info. So it may be more reasonable to depend on BOOTMEM_INFO_NODE. Just my thoughts. Thanks. > > At first my idea was to free vmemmap pages through the bootmem > interface. My first instinct is to rely on BOOTMEM_INFO_NODE. > It makes sense to me to depend on CONFIG_SPARSE. I will > update this in the next version. > > Thanks. > > > > > This doesn't matter right now because it seems that the *_page_bootmem > > is only used by x86 outside of the memory hotplug. > > > > Other than that looks good to me. > > -- > > Michal Hocko > > SUSE Labs