From: Oscar Salvador <osalvador@suse.de>
To: ackerleytng@google.com
Cc: Muchun Song <muchun.song@linux.dev>,
David Hildenbrand <david@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
fvdl@google.com, jiaqiyan@google.com, joshua.hahnjy@gmail.com,
jthoughton@google.com, mhocko@kernel.org, michael.roth@amd.com,
pasha.tatashin@soleen.com, pbonzini@redhat.com,
peterx@redhat.com, pratyush@kernel.org,
rick.p.edgecombe@intel.com, rientjes@google.com,
roman.gushchin@linux.dev, seanjc@google.com,
shakeel.butt@linux.dev, shivankg@amd.com, vannapurve@google.com,
yan.y.zhao@intel.com, Dan Williams <djbw@kernel.org>,
Jason Gunthorpe <jgg@ziepe.ca>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/6] Open HugeTLB allocation routine for more generic use
Date: Tue, 12 May 2026 15:17:56 +0200 [thread overview]
Message-ID: <agMohIaXKLlBKM6A@localhost.localdomain> (raw)
In-Reply-To: <20260506-hugetlb-open-up-v2-0-826a0c5f28fc@google.com>
On Wed, May 06, 2026 at 08:54:36AM -0700, Ackerley Tng via B4 Relay wrote:
> Hi,
>
> The motivation for this patch series is guest_memfd, which would like
> to use HugeTLB as a generic source of huge pages but not adopt
> HugeTLB's reservation at mmap() time.
>
> By refactoring alloc_hugetlb_folio() and some dependent functions,
> there is now an option to allocate HugeTLB folios without providing a
> VMA. Specifically, HugeTLB allocation used to be dependent on the VMA
> to
>
> 1. Look up reservations in the resv_map
> 2. Get mpol, stored at vma->vm_policy
>
> This refactoring provides hugetlb_alloc_folio(), which focuses on just
> the allocation itself, and associated memory and HugeTLB charging
> (cgroups). alloc_hugetlb_folio() still handles reservations in the
> resv_map and subpools.
>
> Regarding naming, I'm definitely open to alternative names :) I chose
> hugetlb_alloc_folio() because I'm seeing this function as a general
> allocation function that is provided by the HugeTLB subsystem (hence
> the hugetlb_ prefix). I'm intending for alloc_hugetlb_folio() to be
> later refactored as a static function for use just by HugeTLB, and
> HugeTLBfs should probably use hugetlb_alloc_folio() directly.
>
> To see how hugetlb_alloc_folio() is used by guest_memfd, the most
> recent patch series that uses this more generic HugeTLB allocation
> routine is at [1], and a newer revision of that patch series is at
> [2].
Would that be
https://lore.kernel.org/all/cover.1747264138.git.ackerleytng@google.com/T/#me2152fa2cc79d651ecea7a2bce8b57725fb57465
?
--
Oscar Salvador
SUSE Labs
prev parent reply other threads:[~2026-05-12 13:18 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-06 15:54 [PATCH v2 0/6] Open HugeTLB allocation routine for more generic use Ackerley Tng
2026-05-06 15:54 ` Ackerley Tng via B4 Relay
2026-05-06 15:54 ` [PATCH v2 1/6] mm: hugetlb: Consolidate interpretation of gbl_chg within alloc_hugetlb_folio() Ackerley Tng
2026-05-06 15:54 ` Ackerley Tng via B4 Relay
2026-05-12 9:00 ` Oscar Salvador
2026-05-06 15:54 ` [PATCH v2 2/6] mm: hugetlb: Move mpol interpretation out of alloc_buddy_hugetlb_folio_with_mpol() Ackerley Tng
2026-05-06 15:54 ` Ackerley Tng via B4 Relay
2026-05-12 12:51 ` Oscar Salvador
2026-05-06 15:54 ` [PATCH v2 3/6] mm: hugetlb: Move mpol interpretation out of dequeue_hugetlb_folio_vma() Ackerley Tng
2026-05-06 15:54 ` Ackerley Tng via B4 Relay
2026-05-12 12:56 ` Oscar Salvador
2026-05-06 15:54 ` [PATCH v2 4/6] mm: hugetlb: Use error variable in alloc_hugetlb_folio Ackerley Tng
2026-05-06 15:54 ` Ackerley Tng via B4 Relay
2026-05-06 15:54 ` [PATCH v2 5/6] mm: hugetlb: Move mem_cgroup_charge_hugetlb() earlier in allocation Ackerley Tng
2026-05-06 15:54 ` Ackerley Tng via B4 Relay
2026-05-06 15:54 ` [PATCH v2 6/6] mm: hugetlb: Refactor out hugetlb_alloc_folio() Ackerley Tng
2026-05-06 15:54 ` Ackerley Tng via B4 Relay
2026-05-12 13:25 ` Oscar Salvador
2026-05-12 13:17 ` Oscar Salvador [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=agMohIaXKLlBKM6A@localhost.localdomain \
--to=osalvador@suse.de \
--cc=ackerleytng@google.com \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=djbw@kernel.org \
--cc=fvdl@google.com \
--cc=jgg@ziepe.ca \
--cc=jiaqiyan@google.com \
--cc=joshua.hahnjy@gmail.com \
--cc=jthoughton@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=michael.roth@amd.com \
--cc=muchun.song@linux.dev \
--cc=pasha.tatashin@soleen.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=pratyush@kernel.org \
--cc=rick.p.edgecombe@intel.com \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=seanjc@google.com \
--cc=shakeel.butt@linux.dev \
--cc=shivankg@amd.com \
--cc=vannapurve@google.com \
--cc=yan.y.zhao@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.