All of lore.kernel.org
 help / color / mirror / Atom feed
From: Huacai Chen <chenhuacai@kernel.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Huacai Chen <chenhuacai@loongson.cn>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	 Dave Hansen <dave.hansen@linux.intel.com>,
	Andy Lutomirski <luto@kernel.org>,
	 Peter Zijlstra <peterz@infradead.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	 Will Deacon <will@kernel.org>,
	loongarch@lists.linux.dev,
	 linux-arch <linux-arch@vger.kernel.org>,
	Xuefeng Li <lixuefeng@loongson.cn>,  Guo Ren <guoren@kernel.org>,
	Xuerui Wang <kernel@xen0n.name>,
	 Jiaxun Yang <jiaxun.yang@flygoat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	 Linux-MM <linux-mm@kvack.org>,
	 "open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
	 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	 Linux ARM <linux-arm-kernel@lists.infradead.org>,
	 Feiyang Chen <chenfeiyang@loongson.cn>
Subject: Re: [PATCH V2 3/4] mm/sparse-vmemmap: Generalise vmemmap_populate_hugepages()
Date: Thu, 30 Jun 2022 16:27:53 +0800	[thread overview]
Message-ID: <CAAhV-H5kywXfSLaKRhobqzozOuU0UyEKcOApu3Abz+csCgJPgg@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a1f94z4oSnMr73PuiXkMR7uGhthzY_EWVniB+G4KXBcBQ@mail.gmail.com>

Hi, Arnd,

On Thu, Jun 30, 2022 at 2:05 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Thu, Jun 30, 2022 at 6:32 AM Huacai Chen <chenhuacai@loongson.cn> wrote:
> >
> > From: Feiyang Chen <chenfeiyang@loongson.cn>
> >
> > 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 <chenhuacai@loongson.cn>
> > Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
>
> 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

WARNING: multiple messages have this Message-ID (diff)
From: Huacai Chen <chenhuacai@kernel.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Huacai Chen <chenhuacai@loongson.cn>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	 Dave Hansen <dave.hansen@linux.intel.com>,
	Andy Lutomirski <luto@kernel.org>,
	 Peter Zijlstra <peterz@infradead.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	 Will Deacon <will@kernel.org>,
	loongarch@lists.linux.dev,
	 linux-arch <linux-arch@vger.kernel.org>,
	Xuefeng Li <lixuefeng@loongson.cn>,  Guo Ren <guoren@kernel.org>,
	Xuerui Wang <kernel@xen0n.name>,
	 Jiaxun Yang <jiaxun.yang@flygoat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	 Linux-MM <linux-mm@kvack.org>,
	 "open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
	 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	 Linux ARM <linux-arm-kernel@lists.infradead.org>,
	 Feiyang Chen <chenfeiyang@loongson.cn>
Subject: Re: [PATCH V2 3/4] mm/sparse-vmemmap: Generalise vmemmap_populate_hugepages()
Date: Thu, 30 Jun 2022 16:27:53 +0800	[thread overview]
Message-ID: <CAAhV-H5kywXfSLaKRhobqzozOuU0UyEKcOApu3Abz+csCgJPgg@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a1f94z4oSnMr73PuiXkMR7uGhthzY_EWVniB+G4KXBcBQ@mail.gmail.com>

Hi, Arnd,

On Thu, Jun 30, 2022 at 2:05 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Thu, Jun 30, 2022 at 6:32 AM Huacai Chen <chenhuacai@loongson.cn> wrote:
> >
> > From: Feiyang Chen <chenfeiyang@loongson.cn>
> >
> > 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 <chenhuacai@loongson.cn>
> > Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
>
> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-06-30  8:28 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-30  4:32 [PATCH V2 0/4] mm/sparse-vmemmap: Generalise helpers and enable for Huacai Chen
2022-06-30  4:32 ` Huacai Chen
2022-06-30  4:32 ` [PATCH V2 1/4] MIPS&LoongArch: Adjust prototypes of p?d_init() Huacai Chen
2022-06-30  4:32   ` Huacai Chen
2022-06-30  4:32 ` [PATCH V2 2/4] LoongArch: Add sparse memory vmemmap support Huacai Chen
2022-06-30  4:32   ` Huacai Chen
2022-06-30  4:32 ` [PATCH V2 3/4] mm/sparse-vmemmap: Generalise vmemmap_populate_hugepages() Huacai Chen
2022-06-30  4:32   ` Huacai Chen
2022-06-30  6:05   ` Arnd Bergmann
2022-06-30  6:05     ` Arnd Bergmann
2022-06-30  8:27     ` Huacai Chen [this message]
2022-06-30  8:27       ` Huacai Chen
2022-06-30  4:32 ` [PATCH V2 4/4] LoongArch: Enable ARCH_WANT_HUGETLB_PAGE_OPTIMIZE_VMEMMAP Huacai Chen
2022-06-30  4:32   ` Huacai Chen
2022-06-30  6:06   ` Arnd Bergmann
2022-06-30  6:06     ` Arnd Bergmann
2022-06-30  6:55     ` Feiyang Chen
2022-06-30  6:55       ` Feiyang Chen
2022-06-30  8:30 ` [PATCH V2 0/4] mm/sparse-vmemmap: Generalise helpers and enable for Sergei Shtylyov
2022-06-30  8:30   ` Sergei Shtylyov
2022-06-30  8:53   ` Huacai Chen
2022-06-30  8:53     ` Huacai Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAAhV-H5kywXfSLaKRhobqzozOuU0UyEKcOApu3Abz+csCgJPgg@mail.gmail.com \
    --to=chenhuacai@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=chenfeiyang@loongson.cn \
    --cc=chenhuacai@loongson.cn \
    --cc=dave.hansen@linux.intel.com \
    --cc=guoren@kernel.org \
    --cc=jiaxun.yang@flygoat.com \
    --cc=kernel@xen0n.name \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lixuefeng@loongson.cn \
    --cc=loongarch@lists.linux.dev \
    --cc=luto@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tsbogend@alpha.franken.de \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.