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 A48F7C433EF for ; Mon, 27 Jun 2022 16:27:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3F9F78E0002; Mon, 27 Jun 2022 12:27:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3A96E8E0001; Mon, 27 Jun 2022 12:27:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 272778E0002; Mon, 27 Jun 2022 12:27:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 1A7368E0001 for ; Mon, 27 Jun 2022 12:27:51 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id B888280858 for ; Mon, 27 Jun 2022 16:27:50 +0000 (UTC) X-FDA: 79624547100.19.7E38276 Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) by imf22.hostedemail.com (Postfix) with ESMTP id 467D1C0032 for ; Mon, 27 Jun 2022 16:27:50 +0000 (UTC) Received: by mail-pl1-f174.google.com with SMTP id m2so8644898plx.3 for ; Mon, 27 Jun 2022 09:27:50 -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=x/6bDTOr6s2jDltP+JN9TCz9GVlONUi+KfBRN9dX8fA=; b=D6/QQ53Bi3VjonrgoT74XaObZQeHIaX1QRgVMih/yBKvig4gtR2PQz7O6OSAT5ySSY ngq6//CpeG4hv6Madt/uqOZfktppAZ6bIum02Fhr83H/LvkeN3pOShAfTt7M4ApzxEpg A+d68gHFl2nXf7TnAwnzQSj3mOg0dhBAsH3r5x22XucRxwVsF+AHmpXJznFygQnRxut6 dfyJafbuZw8SlS1Py/Mnmcc2fgeys+2ISa+vewcS/dDfkGqfq9DO5Dm7SzPzW+UqKeLP G+VgbxOsCXzP8tsZldoFnmpfrkEgHzcYsupL/DLzlOcUrswArdZC03BcE6k+DhACu09h jABg== 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=x/6bDTOr6s2jDltP+JN9TCz9GVlONUi+KfBRN9dX8fA=; b=7gpXfolllDc0L1Dug8/JW7zI31Ik0yHOT9kpBX/4E3QXdRiwBAR/ub2HFwk/s9VzvT 3pevHPSPXOUxuhh8n0+KiVPzerBKOsbDZLrVdjlhBerUn1sFPBwHG8FJF7Deir9ensuI CH1WYWEf/X7s8w1/WlAfWpPjfLRUuZddarj+CLpbaucnRe49NnPFEgIUforAdu3G1Shs e8+DDQFSA4nKSsLUxoWaoK+FTXvnI6eXxA/5Ga69gY8ZcfcnDA6YmZtZSl7lerzf+PaN IP7vVgPGJJDVHhhysUddpKxHNV+i+kYxE3Eghf7Y6BWxlrmoam/DpFrlKHMNxvW+IxPl VLCg== X-Gm-Message-State: AJIora/zXI6Pkev8SIkjNUnK/jcmd8g+uCbXJdrkcuNnoLtLRYpLw8iV 3u4tC1CCj95WVSroxDiOxsPKCwIoZxpiIXv+I9t+8w== X-Google-Smtp-Source: AGRyM1u44EI+cRVv99T+1xao+WoQpy9Oj/hL6+KeXPghb5GMu6W8P26EVab6FmVEHEDAHE9c4928+UnrMfCPP5A+HDs= X-Received: by 2002:a17:902:e94f:b0:16a:214e:46c1 with SMTP id b15-20020a170902e94f00b0016a214e46c1mr15580760pll.89.1656347269135; Mon, 27 Jun 2022 09:27:49 -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:27:38 -0700 Message-ID: Subject: Re: [RFC PATCH 00/26] hugetlb: Introduce HugeTLB high-granularity mapping To: Mina Almasry Cc: Mike Kravetz , Muchun Song , Peter Xu , David Hildenbrand , David Rientjes , Axel Rasmussen , 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=1656347270; a=rsa-sha256; cv=none; b=aBukMnxFeyX7kp1OfNpSfVOUgIGp0FTpChSLJmKAikb7Reqa1OxYbBi6ciAQV5Mnwdj9gN ZZagp2B+T+/iWwXFG7C5xoJ10x5aruYNXQ1nSg70cUDvtzN//YH27FRoCwPmXl0W4WYDPB AjbrnPMavVUf3Yyi7JC4fGdazpDvWpw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656347270; 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=x/6bDTOr6s2jDltP+JN9TCz9GVlONUi+KfBRN9dX8fA=; b=OAF5KnGtpUpY65kuk7C6yF3BoxR5yEq9SFXarufa3HPhM7WIZQPj8GpWRBTA4RO9y6b7n5 awvRNN+P6a3iFm3+USldxKN6JXG6uRPFNdGrBKPA6k3wIkKeTkPIN6p1abr0NBGW5ltiOL MVOH/brR/Jy/tdmrjNdumpAUPQ7h6Gc= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="D6/QQ53B"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of jthoughton@google.com designates 209.85.214.174 as permitted sender) smtp.mailfrom=jthoughton@google.com X-Stat-Signature: gic44mrnmf59ry51bftieft1r1nwghiw X-Rspamd-Queue-Id: 467D1C0032 Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="D6/QQ53B"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of jthoughton@google.com designates 209.85.214.174 as permitted sender) smtp.mailfrom=jthoughton@google.com X-Rspam-User: X-Rspamd-Server: rspam04 X-HE-Tag: 1656347270-859196 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:41 AM Mina Almasry wrote: > > On Fri, Jun 24, 2022 at 10:37 AM James Houghton wrote: > > > > [trimmed...] > > ---- Userspace API ---- > > > > This patch series introduces a single way to take advantage of > > high-granularity mapping: via UFFDIO_CONTINUE. UFFDIO_CONTINUE allows > > userspace to resolve MINOR page faults on shared VMAs. > > > > To collapse a HugeTLB address range that has been mapped with several > > UFFDIO_CONTINUE operations, userspace can issue MADV_COLLAPSE. We expect > > userspace to know when all pages (that they care about) have been fetched. > > > > Thanks James! Cover letter looks good. A few questions: > > Why not have the kernel collapse the hugepage once all the 4K pages > have been fetched automatically? It would remove the need for a new > userspace API, and AFACT there aren't really any cases where it is > beneficial to have a hugepage sharded into 4K mappings when those > mappings can be collapsed. The reason that we don't automatically collapse mappings is because it would take additional complexity, and it is less flexible. Consider the case of 1G pages on x86: currently, userspace can collapse the whole page when it's all ready, but they can also choose to collapse a 2M piece of it. On architectures with more supported hugepage sizes (e.g., arm64), userspace has even more possibilities for when to collapse. This likely further complicates a potential automatic-collapse solution. Userspace may also want to collapse the mapping for an entire hugepage without completely mapping the hugepage first (this would also be possible by issuing UFFDIO_CONTINUE on all the holes, though). > > > ---- HugeTLB Changes ---- > > > > - Mapcount > > The way mapcount is handled is different from the way that it was handled > > before. If the PUD for a hugepage is not none, a hugepage's mapcount will > > be increased. This scheme means that, for hugepages that aren't mapped at > > high granularity, their mapcounts will remain the same as what they would > > have been pre-HGM. > > > > Sorry, I didn't quite follow this. It says mapcount is handled > differently, but the same if the page is not mapped at high > granularity. Can you elaborate on how the mapcount handling will be > different when the page is mapped at high granularity? I guess I didn't phrase this very well. For the sake of simplicity, consider 1G pages on x86, typically mapped with leaf-level PUDs. Previously, there were two possibilities for how a hugepage was mapped, either it was (1) completely mapped (PUD is present and a leaf), or (2) it wasn't mapped (PUD is none). Now we have a third case, where the PUD is not none but also not a leaf (this usually means that the page is partially mapped). We handle this case as if the whole page was mapped. That is, if we partially map a hugepage that was previously unmapped (making the PUD point to PMDs), we increment its mapcount, and if we completely unmap a partially mapped hugepage (making the PUD none), we decrement its mapcount. If we collapse a non-leaf PUD to a leaf PUD, we don't change mapcount. It is possible for a PUD to be present and not a leaf (mapcount has been incremented) but for the page to still be unmapped: if the PMDs (or PTEs) underneath are all none. This case is atypical, and as of this RFC (without bestowing MADV_DONTNEED with HGM flexibility), I think it would be very difficult to get this to happen. > > > - 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". > > > > - Synchronization > > For existing bits of HugeTLB, synchronization is unchanged. For splitting > > and collapsing HugeTLB PTEs, we require that the i_mmap_rw_sem is held for > > writing, and for doing high-granularity page table walks, we require it to > > be held for reading. > > > > ---- Limitations & Future Changes ---- > > > > This patch series only implements high-granularity mapping for VM_SHARED > > VMAs. I intend to implement enough HGM to support 4K unmapping for memory > > failure recovery for both shared and private mappings. > > > > The memory failure use case poses its own challenges that can be > > addressed, but I will do so in a separate RFC. > > > > Performance has not been heavily scrutinized with this patch series. There > > are places where lock contention can significantly reduce performance. This > > will be addressed later. > > > > The patch series, as it stands right now, is compatible with the VMEMMAP > > page struct optimization[3], as we do not need to modify data contained > > in the subpage page structs. > > > > Other omissions: > > - Compatibility with userfaultfd write-protect (will be included in v1). > > - Support for mremap() (will be included in v1). This looks a lot like > > the support we have for fork(). > > - Documentation changes (will be included in v1). > > - Completely ignores PMD sharing and hugepage migration (will be included > > in v1). > > - Implementations for architectures that don't use GENERAL_HUGETLB other > > than arm64. > > > > ---- Patch Breakdown ---- > > > > Patch 1 - Preliminary changes > > Patch 2-10 - HugeTLB HGM core changes > > Patch 11-13 - HugeTLB HGM page table walking functionality > > Patch 14-19 - HugeTLB HGM compatibility with other bits > > Patch 20-23 - Userfaultfd and collapse changes > > Patch 24-26 - arm64 support and selftests > > > > [1] This used to be called HugeTLB double mapping, a bad and confusing > > name. "High-granularity mapping" is not a great name either. I am open > > to better names. > > I would drop 1 extra word and do "granular mapping", as in the mapping > is more granular than what it normally is (2MB/1G, etc). Noted. :)