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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6A27DC43334 for ; Wed, 20 Jul 2022 09:34:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229686AbiGTJer (ORCPT ); Wed, 20 Jul 2022 05:34:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34756 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229797AbiGTJeq (ORCPT ); Wed, 20 Jul 2022 05:34:46 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 57ED25E328 for ; Wed, 20 Jul 2022 02:34:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1658309684; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dZJQXt6doKuqhqmCeIdZMEV0KmUXZoYN8P0BVRcFtdM=; b=UJTlWW1wXFjspHs3DAtPLwQB/mCEFIZ+AH1q1i66e7tYbp2IsVuCMPLfaIJQDPzfFwwZgE fYH5gkno+B2CQ5/9Oe/k+51zDC8rHtUD/7/GRLZwlwfWea/7iMWfdB1wvgRabndT920vbT Q2d5O6LzuOCet+Of60jnBy51crNvS0M= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-547-RkLLxobWNo-32J2S5cOEdw-1; Wed, 20 Jul 2022 05:34:43 -0400 X-MC-Unique: RkLLxobWNo-32J2S5cOEdw-1 Received: by mail-wr1-f70.google.com with SMTP id n7-20020adfc607000000b0021a37d8f93aso3052978wrg.21 for ; Wed, 20 Jul 2022 02:34:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:organization:in-reply-to :content-transfer-encoding; bh=dZJQXt6doKuqhqmCeIdZMEV0KmUXZoYN8P0BVRcFtdM=; b=QtdMOkoMJ1m4r9R9KvMiLVAPjRL2cQXr1kBYexS/jEOJH8FgMf2BWnyJLClt1Ihxnw vFYtGciWLOmxPoWlKjJ5RTGpVFLIsdE3uY5PgTV6YZjh9n7QGDb8ansJIrabEeS6vIN/ 3q6U4vI5/6hetup3cN5E4a1Q58PmvK5wQkvtJR7gUr0l46fgfgTAh/LcrzULjsIVkPtz XPaK1/e3aAtzUa+ighxc0PhNnEs/0IfFdUSv0p/ngfnTGTxQgAGcNFNaiQq6l1I34B/m 2i46LWojIAF/Pd+H2LhYD8x15s6KZARBX7abblpAcwm9PpnKAo9VfB+z+WopvUS62ko5 bp4w== X-Gm-Message-State: AJIora/LEynyrzbVgtMQJKgmYvV7q+ganxRvewvDKaRjW5IGurl6M8g0 YHW52kSCnDs9yL7JVO1ol3fntnICMoCIlrEkQH38SZP/QBRMyMn7kxFOCRdHBY0QW3BExkHGzlO PxFDBl2V0lQzGfJxYxS/RZw== X-Received: by 2002:adf:e889:0:b0:21d:6510:b750 with SMTP id d9-20020adfe889000000b0021d6510b750mr31445076wrm.498.1658309681810; Wed, 20 Jul 2022 02:34:41 -0700 (PDT) X-Google-Smtp-Source: AGRyM1ulf8qkNkDcp6dk1vwhLiwrg1+3SyvqKhWJWE97+JCOnPrgU25PgHyyorDQgXr5DMo4WjCfFQ== X-Received: by 2002:adf:e889:0:b0:21d:6510:b750 with SMTP id d9-20020adfe889000000b0021d6510b750mr31445053wrm.498.1658309681533; Wed, 20 Jul 2022 02:34:41 -0700 (PDT) Received: from ?IPV6:2003:cb:c706:e00:8d96:5dba:6bc4:6e89? (p200300cbc7060e008d965dba6bc46e89.dip0.t-ipconnect.de. [2003:cb:c706:e00:8d96:5dba:6bc4:6e89]) by smtp.gmail.com with ESMTPSA id n21-20020a05600c4f9500b003a2f2bb72d5sm2347014wmq.45.2022.07.20.02.34.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 Jul 2022 02:34:41 -0700 (PDT) Message-ID: <4216f48f-fdf1-ec1e-b963-6f7fe6ba0f63@redhat.com> Date: Wed, 20 Jul 2022 11:34:37 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH V4 3/4] mm/sparse-vmemmap: Generalise vmemmap_populate_hugepages() Content-Language: en-US To: Huacai Chen , 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 References: <20220704112526.2492342-1-chenhuacai@loongson.cn> <20220704112526.2492342-4-chenhuacai@loongson.cn> <20220705092937.GA552@willie-the-truck> <20220706161736.GC3204@willie-the-truck> From: David Hildenbrand Organization: Red Hat In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org 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. -- Thanks, David / dhildenb