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 0E400CCA488 for ; Fri, 22 Jul 2022 02:31:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 215836B0072; Thu, 21 Jul 2022 22:31:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1C4A66B0073; Thu, 21 Jul 2022 22:31:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0662B8E0001; Thu, 21 Jul 2022 22:31:39 -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 EAD876B0072 for ; Thu, 21 Jul 2022 22:31:38 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id C06E11A0B9D for ; Fri, 22 Jul 2022 02:31:38 +0000 (UTC) X-FDA: 79713159876.12.846E2EE Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf10.hostedemail.com (Postfix) with ESMTP id 55270C000E for ; Fri, 22 Jul 2022 02:31:38 +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 5008762014 for ; Fri, 22 Jul 2022 02:31:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D9725C341D3 for ; Fri, 22 Jul 2022 02:31:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1658457095; bh=Bv0Z0FICQOdzzZtOmPdN9kewP9G1tSHtsQYkNggSg78=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=MMvbxJwtjZ9V+sqiaRsQuUKY/ISMau4BT48l/9uFI4RlTtKRbDfwGoEnGIDec2oFF QsvMHrsn7rD4hbliYT6LlYrb8w6oakHAbPl5X+JqsHSNdtYKtSuJQEQT+aNZiT2WA6 Q4lsCypsfsTaYZxVNkUgfl4JcDSYJ2T9VWtEC3wiW2mGBdmxtj+2LBNY+3kMVRKPN7 nrzSuDHTSJfSkuwhmJqfW8U1t+frEn4lxOzYahDZ196iq0ZNC3fZnOZOdu+anLCUrD iOdIx8BFSISFoFMOvzGSfJUcJpsegVbMhK7UsbeTr5RNZKxV+iz8KP1FWqfqTJoV3f HRbcQM6atx0hQ== Received: by mail-vk1-f177.google.com with SMTP id m30so1543866vkl.4 for ; Thu, 21 Jul 2022 19:31:35 -0700 (PDT) X-Gm-Message-State: AJIora/0S51/SWaltICk7r04XNNInVGsXwt4ocWaVftAZEYgkxCh2Rz3 mj2mfeCg4j73WQuCiqgyZV66G7afkKtJsg8yVu8= X-Google-Smtp-Source: AGRyM1tdBR05heJlN2wID/U6oZAUcOW0xT5eOmboleIrnkZv/wMyjrGAPxc0swFv2LQB8zOUvp7dMgST5m1wpZ0A9hQ= X-Received: by 2002:a1f:9b90:0:b0:374:f09c:876f with SMTP id d138-20020a1f9b90000000b00374f09c876fmr481937vke.12.1658457094710; Thu, 21 Jul 2022 19:31:34 -0700 (PDT) MIME-Version: 1.0 References: <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> <62d9cb2579602_1f553629442@dwillia2-xfh.jf.intel.com.notmuch> In-Reply-To: <62d9cb2579602_1f553629442@dwillia2-xfh.jf.intel.com.notmuch> From: Huacai Chen Date: Fri, 22 Jul 2022 10:31:21 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH V4 3/4] mm/sparse-vmemmap: Generalise vmemmap_populate_hugepages() To: Dan Williams Cc: Will Deacon , David Hildenbrand , 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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658457098; a=rsa-sha256; cv=none; b=v5YuuNk0oNRZUdaALa7ig1R6sj2tNkMpvh1vZRESR7OO3wRmRJJsOY2j71H+WvPBF4xufA 47sZi0QKIOhaSrU/qePqbHEK3Bw79nFXSnmIqrdKtrCjqf1S8oz6d1+54cOKHAuYEoFXI+ S7CkO/NCW4W2OivCfBeaubbPfjT3Te8= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=MMvbxJwt; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf10.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=1658457098; 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=3z3Bn4pTGXzUYlUtpyIsfhQn7P6rWWQvNO3NMfS2eHA=; b=ZlSzXmyYTpxKlcydnWSirhb7NR6eGaZGF62oE0DKSqeRoRlkSI8GpUQa2WyR7hgJql7pA+ VAki+rR8vPaqFQUWuiLgKaeUJ31V4a0lvZKMYbpMO+WAAC1wbP5GBDVFpIHIQhWchrvzIx 1gpcyZ+monw0KC/2wY2bgrmYJy01DbM= X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 55270C000E X-Stat-Signature: 7ni79jkxb8oktx3zjm3ziy98gh3zo1et Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=MMvbxJwt; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf10.hostedemail.com: domain of chenhuacai@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chenhuacai@kernel.org X-HE-Tag: 1658457098-353970 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, Dan, On Fri, Jul 22, 2022 at 5:54 AM Dan Williams wrote: > > Huacai Chen wrote: > > 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. > > Apologies for coming late to the party here, original ping came while I > was on vacation and I only just now noticed the direct questions. All > resolved now or is a question still pending? I updated the patch and added a detailed comment based on David's explanation [1]. If that description is correct, I think there are no more questions. Thank you. [1] https://lore.kernel.org/loongarch/20220721130419.1904711-4-chenhuacai@loongson.cn/T/#u Huacai >