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 11FE7CCA47B for ; Thu, 14 Jul 2022 12:34:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3BAE49401A7; Thu, 14 Jul 2022 08:34:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 344109401A5; Thu, 14 Jul 2022 08:34:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 20AF99401A7; Thu, 14 Jul 2022 08:34:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 0D1919401A5 for ; Thu, 14 Jul 2022 08:34:25 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id CFC3A3261E for ; Thu, 14 Jul 2022 12:34:24 +0000 (UTC) X-FDA: 79685648448.02.201A419 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf25.hostedemail.com (Postfix) with ESMTP id 6FA9CA0084 for ; Thu, 14 Jul 2022 12:34:23 +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 8C1C461F2F for ; Thu, 14 Jul 2022 12:34:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E6C95C341D5 for ; Thu, 14 Jul 2022 12:34:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1657802061; bh=qBirXXWP2MvpS4lCr+loYwR+cC50dveyyNNYEAD0Bqs=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=knaJXlPNMLbIxCYOYMKHQqEMkMwL8qRRGZXzl/1Qohf6zRJ4xd5gHTnKhqZGWjL5z IE3X3Bjl8UC8cPhRzT8Lo1Z77YCok4yj9Li87twVXITrGIy5y0GSYPTriXuzrL1ZRd So5VG7MxrP7o5O2V7W9WewYzwer1iy2NrPvjAe+fJ+BQlJcSROjm4xmXwPYlK9qtjL N9MlAm+IdGj8Lrx/MtDnSYWoQX2tVJlDZBeQbkBOwGGPU9MwhV3RYTqhi+0Sni30X3 VfzICXYjlk9lNLCwb4yVi+zsq16JVeK8ufwSXNeZ1D1dXediYjTaoI56H6W/usVSjy pHwz+P4RBhSFw== Received: by mail-vs1-f47.google.com with SMTP id d187so1292170vsd.10 for ; Thu, 14 Jul 2022 05:34:21 -0700 (PDT) X-Gm-Message-State: AJIora/06QiVaV/gtd9bHVQxCt7fwtXJW8yOOZDftijyDdJU50f+d5pQ S8IvN8LXVy834zfZ35aKmrI0WCbRXh/MBKUc1H8= X-Google-Smtp-Source: AGRyM1ty5yRBbaVRJ8PJWbtdv5Dy7XJuthHHzmRMybTtmDUVI2vw0cugeBgictCY0ND5UquBP9+bozDTgNcHp02K6aM= X-Received: by 2002:a67:6fc3:0:b0:356:18:32ba with SMTP id k186-20020a676fc3000000b00356001832bamr3253584vsc.43.1657802060763; Thu, 14 Jul 2022 05:34:20 -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> In-Reply-To: From: Huacai Chen Date: Thu, 14 Jul 2022 20:34:08 +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 , 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=1657802063; a=rsa-sha256; cv=none; b=MfG6PyUowLBMKwnwH5nelZgUx3DYK6VRGObARoudOZWjwNhcWCOUkSpP5ZsQqQuOwRbcSM 6KjhQ7SjX2ayPQTQl4V6pnJAO8BFObDo7C3GFsqlSMChbMEVamtrUM7vCSA28C5OYj669w 2WEfD9rKRk+kMI6FyLkN4WKjo/x7yJ8= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=knaJXlPN; spf=pass (imf25.hostedemail.com: domain of chenhuacai@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chenhuacai@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657802063; 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=Bhpb2LA+RHXsUq6fiH7RddhubCiiG9YV8RfiQ4PSG8c=; b=HjT9ZKdMmpzHkYbiyHP3aUem2ahWwm0KxdoqWhKr0mFayikHvaXoU0tcLHrX+7aFl8+0z9 X5wbZGyg8h0+9BzOa7dtzd4mkDnFz/Z03UGEaO/q3+m2dgtx1mlJLmBaZWNvUZColJjplF Mox0S6uwL+FJJU70FPxZC0GDWOD7DAk= X-Rspamd-Queue-Id: 6FA9CA0084 Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=knaJXlPN; spf=pass (imf25.hostedemail.com: domain of chenhuacai@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chenhuacai@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Rspamd-Server: rspam02 X-Rspam-User: X-Stat-Signature: 7hwwd9mqzqfxu9e99i874h5oz53ygzxj X-HE-Tag: 1657802063-130616 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: 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)? > > Huacai > > > > > Will