From: Will Deacon <will@kernel.org>
To: Huacai Chen <chenhuacai@loongson.cn>
Cc: Arnd Bergmann <arnd@arndb.de>,
Huacai Chen <chenhuacai@kernel.org>,
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>,
loongarch@lists.linux.dev, 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@kvack.org, linux-mips@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Feiyang Chen <chenfeiyang@loongson.cn>
Subject: Re: [PATCH V4 3/4] mm/sparse-vmemmap: Generalise vmemmap_populate_hugepages()
Date: Tue, 5 Jul 2022 10:29:37 +0100 [thread overview]
Message-ID: <20220705092937.GA552@willie-the-truck> (raw)
In-Reply-To: <20220704112526.2492342-4-chenhuacai@loongson.cn>
On Mon, Jul 04, 2022 at 07:25:25PM +0800, Huacai Chen wrote:
> From: Feiyang Chen <chenfeiyang@loongson.cn>
>
> Generalise vmemmap_populate_hugepages() so ARM64 & X86 & LoongArch can
> share its implementation.
>
> Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
> ---
> arch/arm64/mm/mmu.c | 53 ++++++-----------------
> arch/loongarch/mm/init.c | 63 ++++++++-------------------
> arch/x86/mm/init_64.c | 92 ++++++++++++++--------------------------
> include/linux/mm.h | 6 +++
> mm/sparse-vmemmap.c | 54 +++++++++++++++++++++++
> 5 files changed, 124 insertions(+), 144 deletions(-)
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 626ec32873c6..b080a65c719d 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -1158,49 +1158,24 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
> return vmemmap_populate_basepages(start, end, node, altmap);
> }
> #else /* !ARM64_KERNEL_USES_PMD_MAPS */
> +void __meminit vmemmap_set_pmd(pmd_t *pmdp, void *p, int node,
> + unsigned long addr, unsigned long next)
> +{
> + pmd_set_huge(pmdp, __pa(p), __pgprot(PROT_SECT_NORMAL));
> +}
> +
> +int __meminit vmemmap_check_pmd(pmd_t *pmdp, int node, unsigned long addr,
> + unsigned long next)
> +{
> + vmemmap_verify((pte_t *)pmdp, node, addr, next);
> + return 1;
> +}
> +
> int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
> struct vmem_altmap *altmap)
> {
> - unsigned long addr = start;
> - unsigned long next;
> - pgd_t *pgdp;
> - p4d_t *p4dp;
> - pud_t *pudp;
> - pmd_t *pmdp;
> -
> WARN_ON((start < VMEMMAP_START) || (end > VMEMMAP_END));
> - do {
> - next = pmd_addr_end(addr, end);
> -
> - pgdp = vmemmap_pgd_populate(addr, node);
> - if (!pgdp)
> - return -ENOMEM;
> -
> - p4dp = vmemmap_p4d_populate(pgdp, addr, node);
> - if (!p4dp)
> - return -ENOMEM;
> -
> - pudp = vmemmap_pud_populate(p4dp, addr, node);
> - if (!pudp)
> - return -ENOMEM;
> -
> - pmdp = pmd_offset(pudp, addr);
> - if (pmd_none(READ_ONCE(*pmdp))) {
> - void *p = NULL;
> -
> - p = vmemmap_alloc_block_buf(PMD_SIZE, node, altmap);
> - if (!p) {
> - if (vmemmap_populate_basepages(addr, next, node, altmap))
> - return -ENOMEM;
> - continue;
> - }
> -
> - pmd_set_huge(pmdp, __pa(p), __pgprot(PROT_SECT_NORMAL));
> - } else
> - vmemmap_verify((pte_t *)pmdp, node, addr, next);
> - } while (addr = next, addr != end);
> -
> - return 0;
> + return vmemmap_populate_hugepages(start, end, node, altmap);
> }
> #endif /* !ARM64_KERNEL_USES_PMD_MAPS */
I think the arm64 change is mostly ok (thanks!), but I have a question about
the core code you're introducing:
> diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c
> 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;
> +}
> +
> +int __meminit vmemmap_populate_hugepages(unsigned long start, unsigned long end,
> + int node, struct vmem_altmap *altmap)
> +{
> + unsigned long addr;
> + unsigned long next;
> + pgd_t *pgd;
> + p4d_t *p4d;
> + pud_t *pud;
> + pmd_t *pmd;
> +
> + for (addr = start; addr < end; addr = next) {
> + next = pmd_addr_end(addr, end);
> +
> + pgd = vmemmap_pgd_populate(addr, node);
> + if (!pgd)
> + return -ENOMEM;
> +
> + p4d = vmemmap_p4d_populate(pgd, addr, node);
> + if (!p4d)
> + return -ENOMEM;
> +
> + pud = vmemmap_pud_populate(p4d, addr, node);
> + if (!pud)
> + return -ENOMEM;
> +
> + pmd = pmd_offset(pud, addr);
> + if (pmd_none(READ_ONCE(*pmd))) {
> + void *p;
> +
> + p = vmemmap_alloc_block_buf(PMD_SIZE, node, altmap);
> + if (p) {
> + vmemmap_set_pmd(pmd, p, node, addr, next);
> + continue;
> + } else if (altmap)
> + return -ENOMEM; /* no fallback */
Why do you return -ENOMEM if 'altmap' here? That seems to be different to
what we currently have on arm64 and it's not clear to me why we're happy
with an altmap for the pmd case, but not for the pte case.
Will
next prev parent reply other threads:[~2022-07-05 9:29 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-04 11:25 [PATCH V4 0/4] mm/sparse-vmemmap: Generalise helpers and enable for LoongArch Huacai Chen
2022-07-04 11:25 ` [PATCH V4 1/4] MIPS&LoongArch: Adjust prototypes of p?d_init() Huacai Chen
2022-07-04 11:25 ` [PATCH V4 2/4] LoongArch: Add sparse memory vmemmap support Huacai Chen
2022-07-04 11:25 ` [PATCH V4 3/4] mm/sparse-vmemmap: Generalise vmemmap_populate_hugepages() Huacai Chen
2022-07-05 9:29 ` Will Deacon [this message]
2022-07-05 13:07 ` Huacai Chen
2022-07-06 16:17 ` Will Deacon
2022-07-08 9:47 ` Huacai Chen
2022-07-14 12:34 ` Huacai Chen
2022-07-20 9:34 ` David Hildenbrand
2022-07-21 2:08 ` Huacai Chen
2022-07-21 9:55 ` Will Deacon
2022-07-21 13:01 ` Huacai Chen
2022-07-21 21:54 ` Dan Williams
2022-07-22 2:31 ` Huacai Chen
2022-07-04 11:25 ` [PATCH V4 4/4] LoongArch: Enable ARCH_WANT_HUGETLB_PAGE_OPTIMIZE_VMEMMAP Huacai Chen
2022-07-04 12:18 ` Arnd Bergmann
2022-07-05 6:21 ` Huacai Chen
2022-07-05 7:51 ` Muchun Song
2022-07-05 8:05 ` Arnd Bergmann
2022-07-05 8:38 ` Muchun Song
2022-07-05 8:45 ` Arnd Bergmann
2022-07-05 9:12 ` Muchun Song
2022-07-05 10:49 ` Feiyang 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=20220705092937.GA552@willie-the-truck \
--to=will@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=chenfeiyang@loongson.cn \
--cc=chenhuacai@kernel.org \
--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 \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox