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 89434C43334 for ; Mon, 27 Jun 2022 16:48:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2C8598E0003; Mon, 27 Jun 2022 12:48:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 278598E0001; Mon, 27 Jun 2022 12:48:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1404C8E0003; Mon, 27 Jun 2022 12:48:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 04BB98E0001 for ; Mon, 27 Jun 2022 12:48:43 -0400 (EDT) Received: from smtpin31.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id D278D35069 for ; Mon, 27 Jun 2022 16:48:42 +0000 (UTC) X-FDA: 79624599684.31.22BE993 Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com [209.85.216.54]) by imf18.hostedemail.com (Postfix) with ESMTP id A814B1C0033 for ; Mon, 27 Jun 2022 16:48:40 +0000 (UTC) Received: by mail-pj1-f54.google.com with SMTP id w19-20020a17090a8a1300b001ec79064d8dso13058470pjn.2 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=DbAQ2FNLx2MTpp0UVg57PhW3Lt8InWt6K92r/LkHaZmdXrqkovRvQ6Gm6bE5gRkErP 8u3Fk2UpoRK9v9Ie4rgEri6lGky3pHf0H/bg/eDFRbAirJ785cUSZz+/BL0KDF03H2Dd NJU8WVM1390OzQvEFKwSyQzoylwE/FQwRr5dRPRMOMTZFaICODQZF8gBpOeAjvhCbKjl /TKu4FcGb2AnCpwatTblLZhpxkeUGHlO1CrQZDzYfWh6m4OyUKCJjDeS5yrUUo7/6HO8 XQCKCvs7IH1oRNFt7pXZQFC0wOzcr7hL0zxSao6zs4q4bbzsU9hCI0OUZrRYDZ5NQcLI zztw== X-Gm-Message-State: AJIora/1AvFQZkYgg4HwMulaWYsyyYkbhP1bPa67N4VmaK/PKCyhBI+N 9p54ZwbLXv9qISMkyZdBwKJGuK1F1naExur9S1I41w== X-Google-Smtp-Source: AGRyM1sX7Vhn+yEBOB2idsT35DSBVtMO8mXoQcJ7fPN60gbm72EjQuxU1i7V3VmIapFGKTMyi/ggNbZ1UwR4Is/rrJ4= 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" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656348522; a=rsa-sha256; cv=none; b=R+cPv0S3m2UL3S1JYYkT8utPXPKsMaeBT5LYrIL/600k7xs4IR/ZjhxpIiVsxwS+mU/BbO a57lkAhMcI2ul/SA2uOmLFLhAA/fB+AK2qxI8+5fekzl5/oq/90FlPlRAR1MWnd6oxxMhU W7eYYTB4ZQ2NlyH5ja34uM8TSn+llPE= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=iJvgJ0mS; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf18.hostedemail.com: domain of jthoughton@google.com designates 209.85.216.54 as permitted sender) smtp.mailfrom=jthoughton@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656348522; 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=JK+x8HHa/lHbi1+M/aXyrWBlrZRg6SDvk2Gogvlt21Y=; b=sfjgI6HJDLI58sx9JGZ2bHy1UBYCcpozEINFcYKhy2PuOZmNUOCaAyTZQjb83NVnogf5Rq 1PXO4NQl4c4DCBvHG/Xt/inWBbbC38GaBroy3u1CqCADng3aaaWe2HubrZO4umKbHgC7vx amdoX/aB0kkxaK5aZTliAB90mDK8lN8= X-Stat-Signature: 7pxmsxzkj1wm7hdcjiay6cdozz4qaefq X-Rspam-User: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: A814B1C0033 Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=iJvgJ0mS; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf18.hostedemail.com: domain of jthoughton@google.com designates 209.85.216.54 as permitted sender) smtp.mailfrom=jthoughton@google.com X-HE-Tag: 1656348520-251706 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: 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.