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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 39730C43334 for ; Thu, 30 Jun 2022 08:28:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C82088E0001; Thu, 30 Jun 2022 04:28:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C31D76B0073; Thu, 30 Jun 2022 04:28:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AF8C38E0001; Thu, 30 Jun 2022 04:28:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 9DEB66B0072 for ; Thu, 30 Jun 2022 04:28:10 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 65C86348F6 for ; Thu, 30 Jun 2022 08:28:10 +0000 (UTC) X-FDA: 79634224740.17.F7B40EE Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf28.hostedemail.com (Postfix) with ESMTP id DBBFFC0041 for ; Thu, 30 Jun 2022 08:28:09 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 0043861EF3 for ; Thu, 30 Jun 2022 08:28:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 53EDBC341D3 for ; Thu, 30 Jun 2022 08:28:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1656577687; bh=SkqClHc7drj1TyPDl23yksWfycVYMTWrSPIUHoyfEwE=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=B7CPMIbhC1C2mpkc3aoWjdmyrIVGqtmC9zFMsPeE1twNFdxgdBwruNn9qlvq8jzmX b03vb4SBq2jZqMvhnz6275h/IvCA4d/VfOrPuNA5rzaHdo29eitnlBN1wIs7Nmd0CR t0Gkex5Mr/Gtcew15u8uW4194ALBx15jBKU/1NqqQxEExH85aA42xfX63VYP+ugC+i j0K069hCdHJbRgrll1Czxbqz5fUNEfMB0Punsrjm2p8Uo5vaZsWTT4nSiLhSEbYU5G ZQnWhtgOV9XEzpRWWmolnlYDZNX7CKsEpxY6zkvLG69hHnu/NQy3A4yHfbFmEPM4m7 Qsg1KIf2WNBPQ== Received: by mail-vk1-f180.google.com with SMTP id m188so8653520vkm.3 for ; Thu, 30 Jun 2022 01:28:07 -0700 (PDT) X-Gm-Message-State: AJIora9fkn5NNLQgnVpjbEPPotQJuFb7xpSUfhrSILBAyBys7MgZB5Hv nnvMkURsqns+WpCpGAVGdqliCbUb53qoch9CpMo= X-Google-Smtp-Source: AGRyM1t6MEV6NE/9g+uMmfb0idguxwxwLsxO+IOwvim6D9NJDdUn8BK07k7k+g6g0DwK3bhD1CtaM6+xNPvZKqjZrrA= X-Received: by 2002:a1f:2a86:0:b0:370:8ff3:d5f with SMTP id q128-20020a1f2a86000000b003708ff30d5fmr3791575vkq.35.1656577686160; Thu, 30 Jun 2022 01:28:06 -0700 (PDT) MIME-Version: 1.0 References: <20220630043237.2059576-1-chenhuacai@loongson.cn> <20220630043237.2059576-4-chenhuacai@loongson.cn> In-Reply-To: From: Huacai Chen Date: Thu, 30 Jun 2022 16:27:53 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH V2 3/4] mm/sparse-vmemmap: Generalise vmemmap_populate_hugepages() To: Arnd Bergmann Cc: Huacai Chen , Thomas Bogendoerfer , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Catalin Marinas , Will Deacon , loongarch@lists.linux.dev, linux-arch , Xuefeng Li , Guo Ren , Xuerui Wang , Jiaxun Yang , Andrew Morton , Linux-MM , "open list:BROADCOM NVRAM DRIVER" , Linux Kernel Mailing List , Linux ARM , Feiyang Chen Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656577690; a=rsa-sha256; cv=none; b=7q/x1pRvAl06pVUxpqS8V4e83Sl5INUxwqfIGQHVSq5pcdV/TL8JNCPttuK4IhxHEe20XT IjYhQ5RqdiclGEflDc9A1g8269dt4ELMSPjX0G/meH1aHY+TDq/2aZN3CfEcszQfavsB62 9vj1/3naG+32qA+m/mk4h5n4bgyfrZ8= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=B7CPMIbh; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf28.hostedemail.com: domain of chenhuacai@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chenhuacai@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656577690; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ydbbzmyvSbnE+JeMSUHT6PsXCELrpgO0M6vDiILnz+E=; b=7H2CrTXMkf4mHbQIVVc1Mc5LC05ASbcBLN7kmnsL9BR/JTfaPdl53GJvfgU9RLKYckL5GY zfB3BUPi/lwLUvdMfH/NBBRfQwVmlDjy25a1riM9kFtLAOr8uGuawGqa4Y5q6H/+dY6M5p 0KciC6vClCgyH9kumlWeuOh58iXfIiM= X-Stat-Signature: ho668d5j6dc9co4pon3b68igp9rj6b7f X-Rspamd-Queue-Id: DBBFFC0041 Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=B7CPMIbh; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf28.hostedemail.com: domain of chenhuacai@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chenhuacai@kernel.org X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1656577689-171788 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: Hi, Arnd, On Thu, Jun 30, 2022 at 2:05 PM Arnd Bergmann wrote: > > On Thu, Jun 30, 2022 at 6:32 AM Huacai Chen wrote: > > > > From: Feiyang Chen > > > > Generalise vmemmap_populate_hugepages() so ARM64 & X86 & LoongArch can > > share its implementation. > > Sharing this function is good, thanks for consolidating this > > > Signed-off-by: Huacai Chen > > Signed-off-by: Feiyang Chen > > The Signed-off-by lines are in the wrong order, it should start with the author > and end with the final submitter. OK, I will change the order. > > > index 33e2a1ceee72..6f2e40bb695d 100644 > > --- a/mm/sparse-vmemmap.c > > +++ b/mm/sparse-vmemmap.c > > @@ -686,6 +686,60 @@ int __meminit vmemmap_populate_basepages(unsigned long start, unsigned long end, > > return vmemmap_populate_range(start, end, node, altmap, NULL); > > } > > > > +void __weak __meminit vmemmap_set_pmd(pmd_t *pmd, void *p, int node, > > + unsigned long addr, unsigned long next) > > +{ > > +} > > + > > +int __weak __meminit vmemmap_check_pmd(pmd_t *pmd, int node, unsigned long addr, > > + unsigned long next) > > +{ > > + return 0; > > +} > > + > > I think inline functions would be better here, both for compiler optimization > and to make it easier to track the code flow. The normal way we do these > in architecture specific headers is to override the functions by defining a > macro of the same name. In my opinion, weak functions are suitable for overriding if they are only used in a single .c file (this case). If we don't use weak functions, this series needs as many as 4 #ifdefs, for pud_init(), pmd_init(), vmemmap_set_pmd() and vmemmap_check_pmd() respectively, which increase the difficulty of maintain (just my own opinion, maybe not a objective fact). Huacai > > > Arnd