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 325CDC05027 for ; Sat, 18 Feb 2023 01:58:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3097F6B0078; Fri, 17 Feb 2023 20:58:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 291AB6B007B; Fri, 17 Feb 2023 20:58:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 10B2E6B007D; Fri, 17 Feb 2023 20:58:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id E820B6B0078 for ; Fri, 17 Feb 2023 20:58:25 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id B3DC1160808 for ; Sat, 18 Feb 2023 01:58:25 +0000 (UTC) X-FDA: 80478752970.22.F52FAD3 Received: from mail-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) by imf04.hostedemail.com (Postfix) with ESMTP id F3D8940004 for ; Sat, 18 Feb 2023 01:58:23 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=lHB21Mhb; spf=pass (imf04.hostedemail.com: domain of almasrymina@google.com designates 209.85.166.43 as permitted sender) smtp.mailfrom=almasrymina@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676685504; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=jBEtaMmv6NuU1ujK88VLXYldYw/2E3HzM87x0/nWuSk=; b=0fIK487fQZPBwhWNTyEx4kZbeaKo8+miSC2nEPCfPY6ZiuvkC6fFLz2qsB8Kc469QqcaAG Rippi53KeCq88hzM+ByhCQAVZa0qevd/lPR6q/Gp9Q2+NREFzK6NYoFZKm83di+vE5I8Zl bRYVzMzCEG8qOHokXjRRKKd2v1H+IXo= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=lHB21Mhb; spf=pass (imf04.hostedemail.com: domain of almasrymina@google.com designates 209.85.166.43 as permitted sender) smtp.mailfrom=almasrymina@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676685504; a=rsa-sha256; cv=none; b=VzCgKPt0nfrYdRMrzd5kfSfc/zsAz5HimCjtFdhngAdL06oRQeLQUR8AC8CnOGYoEBxLKN VxJOYD3zIBstWvaIQh6a6Qx0MATf0I6wd/CKCou8Mi4oNnOEIhOjPs17s/Bzdsp+c7/y6A rLiirsGAN8ogN4neqD6196P1dmKHdAc= Received: by mail-io1-f43.google.com with SMTP id g1so1181155ioe.9 for ; Fri, 17 Feb 2023 17:58:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=jBEtaMmv6NuU1ujK88VLXYldYw/2E3HzM87x0/nWuSk=; b=lHB21MhbsZ8voyCEeWeDja8SxFALo+TWTEPkC2R/uO3n1ngrln5JbuymJG9L1fjUQ5 ZeQJLWjMXCYCEtxL+TZAOn+0Ln4PlLOo4O7N+nlkvUMwyFGsyB5zgCZUJwQ24sc5zVMc PkHR3WsondhJnfiKHvMkPqDYBQF2zKZgs499ISITc737cNoG1btliGXHqo5+9WLtI5Lq G1CgR19YuVuubOgtCSvQDmvHrKdNvbL0+TZbpYbzOeLzswSTvR/AaVBoCFHgPYnr0Ijt 7wpHUXIj5T43gY5tofHF5uoLcn5TnEMsCmmqzVJcJUsFJdxONHAQLSucnT0npJ88DYdL +TfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jBEtaMmv6NuU1ujK88VLXYldYw/2E3HzM87x0/nWuSk=; b=SpzgGoB/1kZbBNg8fUH8uK4rMEVO+U01VTRBfghKo2SQ4mGwpUB/yuaiPvKNYft3M9 aDT4oJ2EnWRWV/F5/Z+F0JpWtuJG63iszCybco0D9cFD1d1jrCUazjhDSFdsPqGLr39Q nZHUX3JYoH+GDzJIShDIXS8EK3L5u2l7dHbhhjqvuJ0I/Knf1nRefxAlBw/r1oISpDy5 fBDV90DgOCshZWzwSAVir/ttLSkkxZ56XOwW7tp0dy0q9I7jyGsKk/xixWegU9eDd2/d wnjXmBiCkww3m6zcJzWiR5lAr+Pj+W0k9bcqNaaQ0PcjJgUgji0TFEJoqDyncGvUiFo2 wAsg== X-Gm-Message-State: AO0yUKWcYpKd6eQJHUhUA040Uq89Yscsy5BUO6WnSN3SScQG44R9I0v0 HCnBVY/UJ7TialwwU8FZR/JV69s2H38WZ/IIAK22vA== X-Google-Smtp-Source: AK7set+hepjXy8mNFLsGdZJtJUCkkYrnLqzv45sd6fQAhj7fw753M+gaxJjummNMV7I8HmdXhMXUAy7ybafJsF7I4j0= X-Received: by 2002:a02:94a4:0:b0:3c5:1490:5775 with SMTP id x33-20020a0294a4000000b003c514905775mr1817884jah.1.1676685502895; Fri, 17 Feb 2023 17:58:22 -0800 (PST) MIME-Version: 1.0 References: <20230218002819.1486479-1-jthoughton@google.com> <20230218002819.1486479-10-jthoughton@google.com> In-Reply-To: <20230218002819.1486479-10-jthoughton@google.com> From: Mina Almasry Date: Fri, 17 Feb 2023 17:58:11 -0800 Message-ID: Subject: Re: [PATCH v2 09/46] mm: add MADV_SPLIT to enable HugeTLB HGM To: James Houghton Cc: Mike Kravetz , Muchun Song , Peter Xu , Andrew Morton , David Hildenbrand , David Rientjes , Axel Rasmussen , "Zach O'Keefe" , Manish Mishra , Naoya Horiguchi , "Dr . David Alan Gilbert" , "Matthew Wilcox (Oracle)" , Vlastimil Babka , Baolin Wang , Miaohe Lin , Yang Shi , Frank van der Linden , Jiaqi Yan , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 4m61k56d8sztunq1p77siowbasqxpmdw X-Rspam-User: X-Rspamd-Queue-Id: F3D8940004 X-Rspamd-Server: rspam06 X-HE-Tag: 1676685503-139127 X-HE-Meta: U2FsdGVkX1+YfZLXbBTdvs39xAo3AJUZN7Pk9MZF4lhrHGmZJfnaj7FHxgMz1Ws6SuQmJGek4IakGTejSVzFQNuzOi1+iBUUF5yXoi7mV508iR0RDpqNclimlGng8LFWwGtqE8acaBgYhfPnSKf3RKLKyhmRxmFvIZEeCQlyqE0pEMge/PDckjMUIwFz1hASWzErIzc1FZ1L1MlYMQm7iyjOceCDr+/uaxENlXZRrO5we1urNIGTZj8RgvcTl9cugEL9FHtgklDep1GYJAhY0qXIxQByOr8+G/aK8ik3OuF0MQvvuqGn5zBgZ8zCyHK4jdAQQstrcXvdlvLqqmA5Pk0+zHPqINqN1Ac4VmeyQX/FBmMk6vgR7PFHkGB+2lh1NbQLGAhttaCPdqkmV6crRdx18WlQQlp0omDVz7lNmJRsre9rmds+p5I4uRtV7Tc27Wvn2yVGjip8Lp0/hyZ/GpblUVGpAwwSBpNK5wu2+N5hdX+w2b5cs4D6onz1ZkODEo4jMAzLObjeq/u3BeaMubiQks36OamSn3zQ0i4rUdnq4FF9v0lKt9NZ3f53L/ISmkMWgbcwE4c23NGjmERHOtiJ3HqTW1svapgQvSDpfguapte/KlbyCUsuwucfa7b7cgXSfKBP69QxMH+hsIlsaCR5FfzHu1T5OZRAR7JXv8xJSSquFhgXhW6aT/MKG+IcWbihAgMVyKs8A2d1t4Q6Jtu+llEBvmw8jvIiyUi97bOiOJxQFdHprN2zn1Lpd8NYX0fAwgpN3ssbFueth0S7MTcgWG6Dnq/ltDYs3qhVKMgsCP83FB5CsnM1MqCGXvFr0/2A2a+Iwzt1Qs3q6SVoX5pEZ/mvdlrkM1tXhveArminoH7Xb6Q9LrjFbBilnkAfklcWLRAdzVGjWR2z/kMhlDmV15slA3MMkKlgzA8MiI4EnbnOUIieWv7R/HhUsx85z4iioGOSdrjOqpsdP6W KINTp/ja fFRNgjCQ5ilbqF+P/vJKxqbZcvtZemfjnLdnzfdy1XCHk2wVCpW3Xubl5mxQMFuOuhO0FAa9ax+7zds7HRt3439iuyKjfR+GtSlmR7xpT8zMozSDUN5TM2tzb9I3wJ1DEa8BbGcE7CVszqoIxnK9+uq/wthxcdg1U2/f4RYbQdhVWx15Yt5bSSZa4d8EZz2VCCc3jquB1OaWIJVuHu/yDp0Q5FlMwYV1tubmMpKeMI1uX5brhI1pMsXbObTjbgQ+2zSX4e6nNvafC+fWhkoN3CJC76Eb3tQ13NyRPS0yuO0jit1d4VM0KTfP+hi+8zMwZ8Hvo 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, Feb 17, 2023 at 4:28=E2=80=AFPM James Houghton wrote: > > Issuing ioctl(MADV_SPLIT) on a HugeTLB address range will enable > HugeTLB HGM. MADV_SPLIT was chosen for the name so that this API can be > applied to non-HugeTLB memory in the future, if such an application is > to arise. > > MADV_SPLIT provides several API changes for some syscalls on HugeTLB > address ranges: > 1. UFFDIO_CONTINUE is allowed for MAP_SHARED VMAs at PAGE_SIZE > alignment. > 2. read()ing a page fault event from a userfaultfd will yield a > PAGE_SIZE-rounded address, instead of a huge-page-size-rounded > address (unless UFFD_FEATURE_EXACT_ADDRESS is used). > > There is no way to disable the API changes that come with issuing > MADV_SPLIT. MADV_COLLAPSE can be used to collapse high-granularity page > table mappings that come from the extended functionality that comes with > using MADV_SPLIT. > So is a hugetlb page or VMA that has been MADV_SPLIT + MADV_COLLAPSE distinct from a hugetlb page or vma that has not been? I thought COLLAPSE would reverse the effects on SPLIT completely. > For post-copy live migration, the expected use-case is: > 1. mmap(MAP_SHARED, some_fd) primary mapping > 2. mmap(MAP_SHARED, some_fd) alias mapping > 3. MADV_SPLIT the primary mapping > 4. UFFDIO_REGISTER/etc. the primary mapping > 5. Copy memory contents into alias mapping and UFFDIO_CONTINUE the > corresponding PAGE_SIZE sections in the primary mapping. > Huh, so MADV_SPLIT doesn't actually split an existing PMD mapping into high granularity mappings. Instead it says that future mappings may be high granularity? I assume they may not even be high granularity, like if the alias mapping faulted in a full hugetlb page (without UFFDIO_CONTINUE) that page would be regular mapped not high granularity mapped. This may be bikeshedding but I do think a clearer name is warranted. Maybe MADV_MAY_SPLIT or something. > More API changes may be added in the future. > > Signed-off-by: James Houghton > > diff --git a/arch/alpha/include/uapi/asm/mman.h b/arch/alpha/include/uapi= /asm/mman.h > index 763929e814e9..7a26f3648b90 100644 > --- a/arch/alpha/include/uapi/asm/mman.h > +++ b/arch/alpha/include/uapi/asm/mman.h > @@ -78,6 +78,8 @@ > > #define MADV_COLLAPSE 25 /* Synchronous hugepage collapse = */ > > +#define MADV_SPLIT 26 /* Enable hugepage high-granulari= ty APIs */ > + > /* compatibility flags */ > #define MAP_FILE 0 > > diff --git a/arch/mips/include/uapi/asm/mman.h b/arch/mips/include/uapi/a= sm/mman.h > index c6e1fc77c996..f8a74a3a0928 100644 > --- a/arch/mips/include/uapi/asm/mman.h > +++ b/arch/mips/include/uapi/asm/mman.h > @@ -105,6 +105,8 @@ > > #define MADV_COLLAPSE 25 /* Synchronous hugepage collapse = */ > > +#define MADV_SPLIT 26 /* Enable hugepage high-granulari= ty APIs */ > + > /* compatibility flags */ > #define MAP_FILE 0 > > diff --git a/arch/parisc/include/uapi/asm/mman.h b/arch/parisc/include/ua= pi/asm/mman.h > index 68c44f99bc93..a6dc6a56c941 100644 > --- a/arch/parisc/include/uapi/asm/mman.h > +++ b/arch/parisc/include/uapi/asm/mman.h > @@ -72,6 +72,8 @@ > > #define MADV_COLLAPSE 25 /* Synchronous hugepage collapse = */ > > +#define MADV_SPLIT 74 /* Enable hugepage high-granulari= ty APIs */ > + > #define MADV_HWPOISON 100 /* poison a page for testing */ > #define MADV_SOFT_OFFLINE 101 /* soft offline page for testing = */ > > diff --git a/arch/xtensa/include/uapi/asm/mman.h b/arch/xtensa/include/ua= pi/asm/mman.h > index 1ff0c858544f..f98a77c430a9 100644 > --- a/arch/xtensa/include/uapi/asm/mman.h > +++ b/arch/xtensa/include/uapi/asm/mman.h > @@ -113,6 +113,8 @@ > > #define MADV_COLLAPSE 25 /* Synchronous hugepage collapse = */ > > +#define MADV_SPLIT 26 /* Enable hugepage high-granulari= ty APIs */ > + > /* compatibility flags */ > #define MAP_FILE 0 > > diff --git a/include/uapi/asm-generic/mman-common.h b/include/uapi/asm-ge= neric/mman-common.h > index 6ce1f1ceb432..996e8ded092f 100644 > --- a/include/uapi/asm-generic/mman-common.h > +++ b/include/uapi/asm-generic/mman-common.h > @@ -79,6 +79,8 @@ > > #define MADV_COLLAPSE 25 /* Synchronous hugepage collapse = */ > > +#define MADV_SPLIT 26 /* Enable hugepage high-granulari= ty APIs */ > + > /* compatibility flags */ > #define MAP_FILE 0 > > diff --git a/mm/madvise.c b/mm/madvise.c > index c2202f51e9dd..8c004c678262 100644 > --- a/mm/madvise.c > +++ b/mm/madvise.c > @@ -1006,6 +1006,28 @@ static long madvise_remove(struct vm_area_struct *= vma, > return error; > } > > +static int madvise_split(struct vm_area_struct *vma, > + unsigned long *new_flags) > +{ > +#ifdef CONFIG_HUGETLB_HIGH_GRANULARITY_MAPPING > + if (!is_vm_hugetlb_page(vma) || !hugetlb_hgm_eligible(vma)) > + return -EINVAL; > + > + /* > + * PMD sharing doesn't work with HGM. If this MADV_SPLIT is on pa= rt > + * of a VMA, then we will split the VMA. Here, we're unsharing be= fore > + * splitting because it's simpler, although we may be unsharing m= ore > + * than we need. > + */ > + hugetlb_unshare_all_pmds(vma); > + > + *new_flags |=3D VM_HUGETLB_HGM; > + return 0; > +#else > + return -EINVAL; > +#endif > +} > + > /* > * Apply an madvise behavior to a region of a vma. madvise_update_vma > * will handle splitting a vm area into separate areas, each area with i= ts own > @@ -1084,6 +1106,11 @@ static int madvise_vma_behavior(struct vm_area_str= uct *vma, > break; > case MADV_COLLAPSE: > return madvise_collapse(vma, prev, start, end); > + case MADV_SPLIT: > + error =3D madvise_split(vma, &new_flags); > + if (error) > + goto out; > + break; > } > > anon_name =3D anon_vma_name(vma); > @@ -1178,6 +1205,9 @@ madvise_behavior_valid(int behavior) > case MADV_HUGEPAGE: > case MADV_NOHUGEPAGE: > case MADV_COLLAPSE: > +#endif > +#ifdef CONFIG_HUGETLB_HIGH_GRANULARITY_MAPPING > + case MADV_SPLIT: > #endif > case MADV_DONTDUMP: > case MADV_DODUMP: > @@ -1368,6 +1398,8 @@ int madvise_set_anon_name(struct mm_struct *mm, uns= igned long start, > * transparent huge pages so the existing pages will not be > * coalesced into THP and new pages will not be allocated as= THP. > * MADV_COLLAPSE - synchronously coalesce pages into new THP. > + * MADV_SPLIT - allow HugeTLB pages to be mapped at PAGE_SIZE. This all= ows > + * UFFDIO_CONTINUE to accept PAGE_SIZE-aligned regions. > * MADV_DONTDUMP - the application wants to prevent pages in the given = range > * from being included in its core dump. > * MADV_DODUMP - cancel MADV_DONTDUMP: no longer exclude from core dump= . > -- > 2.39.2.637.g21b0678d19-goog >