Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp3137012iog; Mon, 27 Jun 2022 09:53:30 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tkwMpBirBUu0hzdTsuvynJ9FednVwkaeDctYbXbIWLUjO+OAKsP0DEnjTMhEA9TSvgI+91 X-Received: by 2002:a17:907:160f:b0:726:9467:9be8 with SMTP id hb15-20020a170907160f00b0072694679be8mr10023793ejc.770.1656348810765; Mon, 27 Jun 2022 09:53:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656348810; cv=none; d=google.com; s=arc-20160816; b=G0Rh+ZpQ3M27Zaod2wK05MBT1FmK85feMeoWAZcA2/4Gx0qyl0GWzU8QpMNcbn9Qfl 80f3b35X4JlKK8qEhLigVfoHYRGYiqogdnGMRcM9Gl4OIFOdNc32GB8hpmzsTw7s4YNw Q0EgHpwfCrKQi9tlelkF3moGdna3K0kxqFvScFM4BrwcoJkXQRj3gXfP6VO3XsXPhk58 Xm84qNPx+S1dPoErjW65seSY5S8baPh0gBIfi/ycJNNcwl/UdHra0puVxc8sO61ZaGf1 IWG7WMGKm2O7cuPCX7F6XZESPP2eR0n/NWPZUI6VKZTdfETsRog3LxejyeMo8n5H+xj2 slWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=JK+x8HHa/lHbi1+M/aXyrWBlrZRg6SDvk2Gogvlt21Y=; b=kXgXJosgrEFTBz95YGS8k5J5WCc/JWwr8+HQlqr3lU5zXoqmf5LR77Xsik4kgNc2ZX TBOgehdg9HzKL9EGhYJi0/1DPGPjrM+lEOAVSpItsAveN4962nP/6J92XoukwIVHWCe8 c7VP9FUDMD+BV0wsOid66mJsLYRXRThaSQrP4Z3gzr3ueeqPUGn5dZvu9E1SjHJT3Urm cTduxtzlca7k8kLjSO7NIEFYOXrWbRsg8fjseKXq1U/S+FT1KPI4XLxws43lRMCK7SxA xTllohfp0povg/CLBLbPT3Kvfji9FaMRcpu6r6nW6qVdfNIVwfXTYtCtquuwvhO0uy28 np9A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=iJvgJ0mS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s15-20020a170906060f00b00718c2c40965si10744658ejb.436.2022.06.27.09.53.03; Mon, 27 Jun 2022 09:53:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=iJvgJ0mS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239604AbiF0Qsp (ORCPT + 99 others); Mon, 27 Jun 2022 12:48:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45446 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239597AbiF0Qsk (ORCPT ); Mon, 27 Jun 2022 12:48:40 -0400 Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 275FA25CF for ; Mon, 27 Jun 2022 09:48:40 -0700 (PDT) Received: by mail-pj1-x102a.google.com with SMTP id 73-20020a17090a0fcf00b001eaee69f600so10012319pjz.1 for ; Mon, 27 Jun 2022 09:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JK+x8HHa/lHbi1+M/aXyrWBlrZRg6SDvk2Gogvlt21Y=; b=iJvgJ0mSW6BG/xkNSTSqwqK2GeiJgOVdQEav7Y8FdBwgfJzO5UE6UhWPNsQBMh0iPj zPZ4jYUsOOVBF7lsYgqXEaKlBPkUjepn0YBPgM/4S9u/J/Ccf/93IpVJv9LVksW+zz31 tfeKlhfOCrHX+jqTrArxkoYvnJYz4NTqbissf1l7+bFiJxXGtXstn34v9nm5cmi72HOk wWifAPCO+v4Xh1xw2YGuwNoKKoXYaVW719DeCmNjmIPieV1bebKf2yUK1JPOaTr+g3fX 1bdeXp3+S6YTfCKGo8AXn166wXEjnS3w0fkFngPnPm0AH4jWvLXhlz034cHxjMmyoezE S37g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JK+x8HHa/lHbi1+M/aXyrWBlrZRg6SDvk2Gogvlt21Y=; b=2VcCgGUj1OJevlaxInKTlubz1EsP/z/Ke7Q6T8EdXr9ExI5VwouGAU9iAUX0BiH3Lu M2mBZadvLQ4bqFDGhD9QGyZwfzOXQYONZju+Ni83FhIH52TcNrtUkrtpxBfbILFvB/rr spgqPGyWJGzfyl7UAft2rQfTLAHXQW4cbhuZ6otkXIjcdH5qDXM2mE65JzVlRCM9uioo xiKsrlxWq8VdJZGPJAW1y7E2HV/y+69+BQbBZPjIylDUeFzrYnfO0fUbZ02RrmDdMKR+ JllF74g2NgCSLZFiokMA0zZvOVq7j2lB8ndc7BCQCn6vht1C84B3oMspI7ciwmHK3BE7 d77w== X-Gm-Message-State: AJIora/7Vzj6fzDEtKukQ0QpIm2AxiMaLdWWSz7iDG5YOHyE58SHOfgz WgF0OVjSrMFxLVahXWAOsyf4KuDTmqu7EGfZCVcOUA== X-Received: by 2002:a17:902:e94f:b0:16a:214e:46c1 with SMTP id b15-20020a170902e94f00b0016a214e46c1mr15674368pll.89.1656348519523; Mon, 27 Jun 2022 09:48:39 -0700 (PDT) MIME-Version: 1.0 References: <20220624173656.2033256-1-jthoughton@google.com> In-Reply-To: From: James Houghton Date: Mon, 27 Jun 2022 09:48:28 -0700 Message-ID: Subject: Re: [RFC PATCH 00/26] hugetlb: Introduce HugeTLB high-granularity mapping To: Matthew Wilcox Cc: Mike Kravetz , Muchun Song , Peter Xu , David Hildenbrand , David Rientjes , Axel Rasmussen , Mina Almasry , Jue Wang , Manish Mishra , "Dr . David Alan Gilbert" , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 24, 2022 at 11:47 AM Matthew Wilcox wrote: > > On Fri, Jun 24, 2022 at 05:36:30PM +0000, James Houghton wrote: > > - Page table walking and manipulation > > A new function, hugetlb_walk_to, handles walking HugeTLB page tables for > > high-granularity mappings. Eventually, it's possible to merge > > hugetlb_walk_to with huge_pte_offset and huge_pte_alloc. > > > > We keep track of HugeTLB page table entries with a new struct, hugetlb_pte. > > This is because we generally need to know the "size" of a PTE (previously > > always just huge_page_size(hstate)). > > > > For every page table manipulation function that has a huge version (e.g. > > huge_ptep_get and ptep_get), there is a wrapper for it (e.g. > > hugetlb_ptep_get). The correct version is used depending on if a HugeTLB > > PTE really is "huge". > > I'm disappointed to hear that page table walking is going to become even > more special. I'd much prefer it if hugetlb walking were exactly the > same as THP walking. This seems like a good time to do at least some > of that work. > > Was there a reason you chose the "more complexity" direction? I chose this direction because it seemed to be the most straightforward to get to a working prototype and then to an RFC. I agree with your sentiment -- I'll see what I can do to reconcile THP walking with HugeTLB(+HGM) walking.