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 1BFF6C433EF for ; Tue, 5 Jul 2022 13:08:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A0BAD6B0073; Tue, 5 Jul 2022 09:08:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 994C06B0074; Tue, 5 Jul 2022 09:08:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 835BA6B0075; Tue, 5 Jul 2022 09:08:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 6FC356B0073 for ; Tue, 5 Jul 2022 09:08:43 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 335B620334 for ; Tue, 5 Jul 2022 13:08:43 +0000 (UTC) X-FDA: 79653075726.22.4478FDA Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf17.hostedemail.com (Postfix) with ESMTP id B749F4005D for ; Tue, 5 Jul 2022 13:08:42 +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 B200661272 for ; Tue, 5 Jul 2022 13:08:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 52A17C341D4 for ; Tue, 5 Jul 2022 13:08:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1657026520; bh=FBpr5Vxk8rpjU3foapuN0AsBsz2vq5+OmGi4f2NIeIM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=EEvPz/rG6h5WvJxeFYRhlWQen0gH9VdMfHsKNvWw0spAc2YL4YZZ4fSVXYiAl+ZZr yR5xLVoup3hf4qC2lPSzBMwG9NDeUL7v1obxWOarttHqheHaEGWswpusSfBd0uohj+ CsWJvDsEg3ls+oPlUBqBejFUb0myJSeM0bYSD3o8D5tfY5M+IaPl4WV5R9Siv9b1mj ZFyRkBi1vEdNAEYLGlg+zp8lpbWmMzna8IEHDvtlJbULN+5HSiyaF19i+Wx7Dh5B9F S22kSDAJK6hMjvSaShaQMXeKzPmbTV/034x2t/XwDsVvQnRGfTdIDcCaz3wNYR+lD5 woKhDCn/UqSgw== Received: by mail-vs1-f50.google.com with SMTP id a184so2728224vsa.1 for ; Tue, 05 Jul 2022 06:08:40 -0700 (PDT) X-Gm-Message-State: AJIora+KDeQduhcHABHNVSlagn314ZREvmkZbgely2GTDvY7fc0mPXg3 5q2vdJZ/PKeyBmi6elJ4Gcj+/OLmOPUOdSDwtfA= X-Google-Smtp-Source: AGRyM1sLv5H5ImzU8A4omTHConu13vLIxH/TbVKFk9gJyyKCawdNyOH0las+ED6pwX9b5yeqM1fF1JPmNgDOz7WFVk4= X-Received: by 2002:a67:d801:0:b0:357:58:f5bc with SMTP id e1-20020a67d801000000b003570058f5bcmr812751vsj.59.1657026519024; Tue, 05 Jul 2022 06:08:39 -0700 (PDT) MIME-Version: 1.0 References: <20220704112526.2492342-1-chenhuacai@loongson.cn> <20220704112526.2492342-4-chenhuacai@loongson.cn> <20220705092937.GA552@willie-the-truck> In-Reply-To: <20220705092937.GA552@willie-the-truck> From: Huacai Chen Date: Tue, 5 Jul 2022 21:07:59 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH V4 3/4] mm/sparse-vmemmap: Generalise vmemmap_populate_hugepages() To: Will Deacon , Dan Williams Cc: Huacai Chen , Arnd Bergmann , Thomas Bogendoerfer , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Catalin Marinas , loongarch@lists.linux.dev, linux-arch , Xuefeng Li , Guo Ren , Xuerui Wang , Jiaxun Yang , Andrew Morton , Linux-MM , "open list:MIPS" , LKML , linux-arm-kernel , Feiyang Chen Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657026522; a=rsa-sha256; cv=none; b=7egfxEIBaKhEGVtYYJL2n85sIZeLeY3qMRIIADyMqipOJG2J/mn3c0tfaMZvepqweCFZ+k U3SgYs4+2MiR2klPZUnlfFRarQaDpZ3FqNhsFM7rwiISsMzBsb+Du+q2aFhpgbYQU+um6r Su8+MVXU7kRcSWYDevoX/7bF6ciCs9o= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="EEvPz/rG"; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf17.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=1657026522; 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=euEEEOGzT2uzpyx6WIl2Q8gpXOb/gPg04vwITc6pvdc=; b=q1voV7U7SsTd3pesgxU6YsJ+Lnkk62t+sXnWh6q3lGeT/QuMPmevpd0hsfOAU1iJBBQPlD dt8VcJUUJNbKO8fKC0ghGg2Ty/bANTQOuTQq0dApgAsrF6Ltm1UjS2Pqc5PfOaPCVBKyGc ohNUpR5AIymN8wBcBWmASnhknJ5cV9s= Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="EEvPz/rG"; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf17.hostedemail.com: domain of chenhuacai@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chenhuacai@kernel.org X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: B749F4005D X-Rspam-User: X-Stat-Signature: 4rseriry1zj77j6a9ywa6sug1zfswkkk X-HE-Tag: 1657026522-29200 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, Will, On Tue, Jul 5, 2022 at 5:29 PM Will Deacon wrote: > > On Mon, Jul 04, 2022 at 07:25:25PM +0800, Huacai Chen wrote: > > From: Feiyang Chen > > > > Generalise vmemmap_populate_hugepages() so ARM64 & X86 & LoongArch can > > share its implementation. > > > > Signed-off-by: Feiyang Chen > > Signed-off-by: Huacai Chen > > --- > > 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. The generic version is the same as X86. It seems that ARM64 always fallback whether there is an altmap, but X86 only fallback in the no altmap case. I don't know the reason of X86, can Dan Williams give some explaination? Huacai > > Will