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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id F3661C43334 for ; Thu, 21 Jul 2022 09:56:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=BPOphWQo6UEsoc+T9LXL4zH6uDG8dEeyin/8SNahD4w=; b=Yp4wJw3/WjJPqN ucjNQv1Ijk+jAE+ud536H9OE01Dt6Iu8m1Ie752w6Xq9cRX7uBuS0f7iclnrEyAKplrPA96QZvjaC t5COGQABS0zkXwyPd3eLPYZ6hiZVbzVWlSL/O0HoyIN7gBFo3Xh4d64pYoVj55yJ43HUmQEIJJ3KR 2kAiMR9pPrwyZ/lr5IDnIQqy6o6IdMq7+KhlTkDSwqqz4Zy32EbAMN2+OqzRapHOOKFMHTU4Uxvlo 39bFH3QCU7vkJwDh0jC+JSfyFII3GYaUCTF4inrAwxzmtZax0Lj35+m+xAeYq9jEeXoPmPuoTOSyH Sqa3yRon/psvHLvFoPTg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oESuG-003YRb-Mu; Thu, 21 Jul 2022 09:55:45 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oESuA-003YOV-6B for linux-arm-kernel@lists.infradead.org; Thu, 21 Jul 2022 09:55:40 +0000 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 1A4CC61F80; Thu, 21 Jul 2022 09:55:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2EF00C3411E; Thu, 21 Jul 2022 09:55:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1658397336; bh=OXWed5vpkzsz0jYpBxkXQrbeEPRaqZHtgrQjnkoQfp0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=NC8h0OOaZSdyUOlE3739Y6vphXUDOgoHE3XwrBc918ss0UlL9dXGVHA25hGA+YvJe XDyM1G5B4/gIgjuL9yHAfq50wfWyrsue7EAa4hzVgkc8J49XYm4oZsTRCnT/Iup/bb 6qswWRDqunoZYVGbDCv5P2i0fsHAStNaFkeDGzL54j8uFSnLgic3tnDtT9Vpgn7hkJ oYBzPUqjW3zMG1+9f+PZKQOVaD8m8uLO8Ni0YWpdWYY5mPbAr9nhVAAG1HiGqHeUK3 zheBGryvqfamq9a5biiKz1jcuE5YG4pdpY0sgA+a6dU49ZxY8WaZjt7JtIsO1uoUZD xtdX/Hb/ah02w== Date: Thu, 21 Jul 2022 10:55:28 +0100 From: Will Deacon To: Huacai Chen 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 Subject: Re: [PATCH V4 3/4] mm/sparse-vmemmap: Generalise vmemmap_populate_hugepages() Message-ID: <20220721095527.GB17088@willie-the-truck> 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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220721_025538_347058_815B1194 X-CRM114-Status: GOOD ( 36.77 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel