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 66ED5C433EF for ; Thu, 21 Jul 2022 02:08:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D5FDD6B0074; Wed, 20 Jul 2022 22:08:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D11118E0002; Wed, 20 Jul 2022 22:08:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BD6EF8E0001; Wed, 20 Jul 2022 22:08:29 -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 AACF76B0074 for ; Wed, 20 Jul 2022 22:08:29 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 74967A07FE for ; Thu, 21 Jul 2022 02:08:29 +0000 (UTC) X-FDA: 79709472738.20.1A73179 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf04.hostedemail.com (Postfix) with ESMTP id ABC1E40067 for ; Thu, 21 Jul 2022 02:08:28 +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 ams.source.kernel.org (Postfix) with ESMTPS id 54AE0B82249 for ; Thu, 21 Jul 2022 02:08:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DFB7CC341CB for ; Thu, 21 Jul 2022 02:08:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1658369303; bh=x2rMvlfF8THw8fAt70svf2hA+mf9vGMD4Y6bBnFyvts=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=QGuO+RmqlkAEDLr2g0opmwbTUo+cz7H4qbtj8xF5E+VbjPHaomN0JJiBUTC0uhjR5 benMLfjKX+j5qBJMvSi8DTYWfgNmy4FXeH3ALFRoBvWyt/rj4qQOlB4sFQ2Dtwn2PA WV97if0XGDsK/oSbZUUc38446D0y/oIzdJFwISPgAC9/pjDB4LI9tXaxKx6I1zg42i NXL0DEkWCTfSXgzD+QgRPO3m2VQovYcL3YHiqcS11N2oo+F3cdl51+JMwME88JYwvD aXkt4mu8jXL1MmEZ5uY5zKpIrVsUJDv9zoO6WyAgSAvtQolHrqWeqtQvNgq4QbAPAg VF/LFLyrkJ5cw== Received: by mail-vs1-f47.google.com with SMTP id q26so273523vsp.11 for ; Wed, 20 Jul 2022 19:08:23 -0700 (PDT) X-Gm-Message-State: AJIora+Kl2H6LGNfRLXXdEmjU47GNEtqcWg0ksvyCVsF74CKwaXW8p+i 6eVVzt7TpL6AhBUuMRDnZhJ/YJoqTvKnzK6+L4M= X-Google-Smtp-Source: AGRyM1vVxa3lqP8AcFV31tQ5vDERIi/melRduGpdj7d9pTPRjhrmeIjSHfa7BiZMsn6SS4xFD7+MeF8wIBRYRpe7hyQ= X-Received: by 2002:a05:6102:3543:b0:357:3ae7:bbd0 with SMTP id e3-20020a056102354300b003573ae7bbd0mr15376874vss.84.1658369302762; Wed, 20 Jul 2022 19:08:22 -0700 (PDT) MIME-Version: 1.0 References: <20220704112526.2492342-1-chenhuacai@loongson.cn> <20220704112526.2492342-4-chenhuacai@loongson.cn> <20220705092937.GA552@willie-the-truck> <20220706161736.GC3204@willie-the-truck> <4216f48f-fdf1-ec1e-b963-6f7fe6ba0f63@redhat.com> In-Reply-To: <4216f48f-fdf1-ec1e-b963-6f7fe6ba0f63@redhat.com> From: Huacai Chen Date: Thu, 21 Jul 2022 10:08:10 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH V4 3/4] mm/sparse-vmemmap: Generalise vmemmap_populate_hugepages() To: David Hildenbrand , Will Deacon , Dan Williams , Sudarshan Rajagopalan 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=1658369309; a=rsa-sha256; cv=none; b=rmq78/N6VLgfQY9DUajU4zd2rLsruXXJMh2LdKJKy4hWy8zotE21lunf1mh0eH+01y6eOc lZmepTQIy8SV9aQhgR8lO1hUG2wEXWaTOPfvOt7pDZrlK8dR1HffSgiry0qJJrDOLUS6hi Hh53ouZhjdIJ4rvUb+jQSPbNPKyIvII= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=QGuO+Rmq; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf04.hostedemail.com: domain of chenhuacai@kernel.org designates 145.40.68.75 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=1658369309; 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=+sWmF+VsIEE489j/B1LeJMYzO0wNvMB0+oyuLWZXbWs=; b=0q4LntrJkkv8yyAbRq79Xv/VMO4hIubezbzmn/DKc3VH1xNkN9IXCdAj3qzt75uKJciOi1 OcnTygr8CyO+iyAhc//0SdxF/GLMskJtyaYI1+S1TEUCoeJ8Pje0PHOV11AYio0NI8UIq3 aKvKsFeSSuUsYY+Jx1ZfaZr7YQbPtk8= X-Rspam-User: Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=QGuO+Rmq; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf04.hostedemail.com: domain of chenhuacai@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=chenhuacai@kernel.org X-Stat-Signature: tzc7rg7br6onmsyumfr9bs5u5m8hxo3p X-Rspamd-Queue-Id: ABC1E40067 X-Rspamd-Server: rspam02 X-HE-Tag: 1658369308-964195 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 Wed, Jul 20, 2022 at 5:34 PM David Hildenbrand wrote: > > On 14.07.22 14:34, Huacai Chen wrote: > > Oh, Sudarshan Rajagopalan's Email has changed, Let's update. > > > > Huacai > > > > On Fri, Jul 8, 2022 at 5:47 PM Huacai Chen wrote: > >> > >> +Dan Williams > >> +Sudarshan Rajagopalan > >> > >> On Thu, Jul 7, 2022 at 12:17 AM Will Deacon wrote: > >>> > >>> On Tue, Jul 05, 2022 at 09:07:59PM +0800, Huacai Chen wrote: > >>>> 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: > >>>>>> 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? > >>> > >>> Right, I think we need to understand the new behaviour here before we adopt > >>> it on arm64. > >> Hi, Dan, > >> Could you please tell us the reason? Thanks. > >> > >> And Sudarshan, > >> You are the author of adding a fallback mechanism to ARM64, do you > >> know why ARM64 is different from X86 (only fallback in no altmap > >> case)? > > I think that's a purely theoretical issue: I assume that in any case we > care about, the altmap should be reasonably sized and aligned such that > this will always succeed. > > To me it even sounds like the best idea to *consistently* fail if there > is no more space in the altmap, even if we'd have to fallback to PTE > (again, highly unlikely that this is relevant in practice). Could > indicate an altmap-size configuration issue. Does David's explanation make things clear? Moreover, I think Dan's dedicated comments "no fallback" implies that his design is carefully considered. So I think the generic version using the X86 logic is just OK. Huacai > > -- > Thanks, > > David / dhildenb > >