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 5F66EC433EF for ; Thu, 21 Jul 2022 13:01:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 74B376B0071; Thu, 21 Jul 2022 09:01:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6FB786B0072; Thu, 21 Jul 2022 09:01:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 574DE6B0074; Thu, 21 Jul 2022 09:01:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 461536B0071 for ; Thu, 21 Jul 2022 09:01:33 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id ED9E51606E8 for ; Thu, 21 Jul 2022 13:01:32 +0000 (UTC) X-FDA: 79711118424.19.013F0C8 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf30.hostedemail.com (Postfix) with ESMTP id 4865C800B4 for ; Thu, 21 Jul 2022 13:01:31 +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 48A8761E3E for ; Thu, 21 Jul 2022 13:01:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CA8FBC341D5 for ; Thu, 21 Jul 2022 13:01:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1658408489; bh=9cehMBtYqegEglWHZ/ZjLkiUCkU1NtN8dr7KiZHOiIw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=r+wK1SAIxaqRJt4LWaDVQXOn4eGCZ2k3lzmMNPWwkQyYuEkVG4+UHvDVsifixH0tZ B3vApo3Ym4XWemOEsITHQb1GQZXN2GDvdEuf18yTM1cEHQ/PmFwLogDa8+EjdVlDuk XpHllkqF+gbXg4IOtwMhBS0OGH0Z7iQFBPLDlNuvbJWcExa9jJmUP6aKS5p72ZXq4u M53QFJ3Jf2MTjlw0f2DJcjCFj4Qxw8+M7Bi11hL8O7inyiBEtZ4tAZOYhe9/puxo8l DgzVe/SSVpitANM7WZMAPekZIFh6HNxJILSMNdU2oRvv6JsFHtK5ZLASdP6WoYlHCb XAf0OW+DUPJsA== Received: by mail-vs1-f41.google.com with SMTP id c3so1450208vsc.6 for ; Thu, 21 Jul 2022 06:01:29 -0700 (PDT) X-Gm-Message-State: AJIora9Q0XuAhBsyISdjvbVt9z7X3Y7DwcPudnfkyuGPmbRuJbXF+3r9 PzqtZEaJXWGlh7kUvpSRTtMNC/OLW1fuKIs+xvo= X-Google-Smtp-Source: AGRyM1sCF40QFVwxOiy6A+lI6fDnfBMtWFc98vxxjozmhn+exqXDjXntJbSCt0dFdaNckfN/rWP+0x+ET0FtuFq5zX8= X-Received: by 2002:a05:6102:3543:b0:357:3ae7:bbd0 with SMTP id e3-20020a056102354300b003573ae7bbd0mr16036189vss.84.1658408488034; Thu, 21 Jul 2022 06:01:28 -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> <20220721095527.GB17088@willie-the-truck> In-Reply-To: <20220721095527.GB17088@willie-the-truck> From: Huacai Chen Date: Thu, 21 Jul 2022 21:01:15 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH V4 3/4] mm/sparse-vmemmap: Generalise vmemmap_populate_hugepages() To: Will Deacon Cc: David Hildenbrand , Dan Williams , Sudarshan Rajagopalan , 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-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=r+wK1SAI; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf30.hostedemail.com: domain of chenhuacai@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chenhuacai@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658408491; a=rsa-sha256; cv=none; b=EIsuwNy0uy1SiV0PbcEuNsxA6kfHcYDMFOICxmIxjBao3F3UeT3Q1YlJ6UryH4FPkLlcNK 7OuCTTUKL2tgP85N6a71zpSuSJUaAMr2mUQEfcjUrwOuVUlJ/LbQuZdIv7lG5uU6wJpZHG sN+VX53+isFBGxMGAuSlY6Qc8u1fBlQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1658408491; 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=4aSMaIwD181BWHv7uBsMNQ4iSjqsk1oYcNhWTNl5B0E=; b=D7R6vtrrLqUWNGirmqFP9JkRLGTHMt6Sl9YkJbdvZ4F4CwQTJgDhJs9HAjt32Y3u+pApM5 n+AzRgb4xjJNtNvZ/rlxfBhajvSOm1Gs04e6v/5LouAeakORIfhzn0FugqAV+OL1qPgtG4 l9B6nOhq4FpMmsCYHG54QWL0a6uiH/4= X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 4865C800B4 Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=r+wK1SAI; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf30.hostedemail.com: domain of chenhuacai@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chenhuacai@kernel.org X-Stat-Signature: zuyba445psd6edhyygb9okwwswokbg9w X-HE-Tag: 1658408491-676691 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 Thu, Jul 21, 2022 at 5:55 PM Will Deacon wrote: > > On Thu, Jul 21, 2022 at 10:08:10AM +0800, Huacai Chen wrote: > > On Wed, Jul 20, 2022 at 5:34 PM David Hildenbrand wrote: > > > On 14.07.22 14:34, Huacai Chen wrote: > > > > On Fri, Jul 8, 2022 at 5:47 PM Huacai Chen wrote: > > > >> 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: > > > >>>>>> +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. > > I think the comment isn't worth the metaphorical paper that it's written > on! If you can bulk it up a bit based on David's reasoning, then that would > help. But yes, I'm happy with the code now, thanks both. OK, I will add a detailed comment here. Huacai > > Will