From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4F3843CE096 for ; Tue, 19 May 2026 08:08:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779178109; cv=none; b=IudqVzi7CkieKfpSsXWEVaB7aUnpWRONkEFygIw+3ngPU0+Ez4HBFLDYzCKMM/s1t5PhVmR2TxtEm50jnZKbyu71dcZjWpux9s0ov0mtZDAXoIty1M0K9wzrECGXacTVXNwOurfDgg4BQ7W7xKRMQjEvM/v2oFzQoUY0CPRZdZY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779178109; c=relaxed/simple; bh=Z5sg7RccpoW46OV1kiETxIaKegge1kxxFQQvSMdVi8g=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Y77Dgins8h3ki40XaTJorYArW9wwtQW/PSxTF497LWD/XoQ+Hgd7UXDouj7Rize7ZGxTTvU8avjYAeQ9aLaLvajXEPd/85o/dapYw1QFNIu99DD0KAa1z5o8StlXWpr+XtcG+/XO4Hj+V9fur+XVnuQVpY9tWbxde5/uC0BQ5wo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=G+ehzlIs; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="G+ehzlIs" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 31B92C2BCB3; Tue, 19 May 2026 08:08:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1779178109; bh=Z5sg7RccpoW46OV1kiETxIaKegge1kxxFQQvSMdVi8g=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=G+ehzlIsd/HSuAHtNo8Lzf/o/Vh9CSDDoXqpEDIPSW2HUziNV2ZnQhJZ+YxJtUSYc actaa0nq3fR5UO46F0zxLzF1bUryf0o45Lz2Y60qp9u7NH4cLSBXQc9FiPHJ9gpYj8 7M999OMwbj8h4ICt1HHt7G3pB2s90aQ+SeoMisqbp9FSJM32TM1AzDKfTSXwkhUg+t q0vv7um5nOQa366TqTy5Xl+uw8/Wi7+M8iwkQg2as8OlaKOtNlGBkcssonRakQlO7r ePDOYNM20q5t+vxJFUJGB/PJm17P3R22xg7LvV/TjesR+I5NJU2grNuMMqU3YHlt6E TK4yOH6X8Igcg== Date: Tue, 19 May 2026 10:08:15 +0200 From: "Oscar Salvador (SUSE)" To: ackerleytng@google.com Cc: Muchun Song , Oscar Salvador , David Hildenbrand , Andrew Morton , 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, Zi Yan , Matthew Brost , Rakie Kim , Byungchul Park , Gregory Price , Ying Huang , Alistair Popple , Dan Williams , Jason Gunthorpe , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 6/6] mm: hugetlb: Refactor out hugetlb_alloc_folio() Message-ID: References: <20260518-hugetlb-open-up-v3-0-e14b302477f8@google.com> <20260518-hugetlb-open-up-v3-6-e14b302477f8@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260518-hugetlb-open-up-v3-6-e14b302477f8@google.com> On Mon, May 18, 2026 at 05:19:45PM -0700, Ackerley Tng via B4 Relay wrote: > From: Ackerley Tng > > Refactor out hugetlb_alloc_folio() from alloc_hugetlb_folio(), which > handles allocation of a folio and memory and HugeTLB charging to cgroups. > > This refactoring decouples the HugeTLB page allocation from VMAs, > specifically: > > 1. Reservations (as in resv_map) are stored in the vma > 2. mpol is stored at vma->vm_policy > 3. A vma must be used for allocation even if the pages are not meant to be > used by host process. > > Without this coupling, VMAs are no longer a requirement for > allocation. This opens up the allocation routine for usage without VMAs, > which will allow guest_memfd to use HugeTLB as a more generic allocator of > huge pages, since guest_memfd memory may not have any associated VMAs by > design. In addition, direct allocations from HugeTLB could possibly be > refactored to avoid the use of a pseudo-VMA. > > Also, this decouples HugeTLB page allocation from HugeTLBfs, where the > subpool is stored at the fs mount. This is also a requirement for > guest_memfd, where the plan is to have a subpool created per-fd and stored > on the inode. > > Provide and use alloc_flags to allow more allocation knobs in future > without expanding the number of parameters in hugetlb_alloc_folio(). > > No functional change intended. > > Signed-off-by: Ackerley Tng I am traveling so I plan to do a more careful review in a few days but I wanted to do some remark: > --- a/mm/hugetlb.c > +++ b/mm/hugetlb.c ... > +struct folio *hugetlb_alloc_folio(struct hstate *h, struct hugepage_subpool *spool, > + gfp_t gfp, struct mempolicy_interpreted *mpoli, > + u8 alloc_flags) > +{ > + bool charge_hugetlb_cgroup_rsvd = alloc_flags & > + HUGETLB_ALLOC_CHARG_CGROUP_RSVD; > + bool use_global_reservation = alloc_flags & > + HUGETLB_ALLOC_USE_GLOBAL_RESERVATIONS; > + size_t nr_pages = pages_per_huge_page(h); > + struct hugetlb_cgroup *h_cg = NULL; > + int idx = hstate_index(h); > + struct folio *folio; > + int ret; IIUC, hugetlb_alloc_folio() will be the gateway function everyone will use from now on to allocate hugetlb pages, that goes for hugetlb itself and external users like guest_memfd. The gfp flag should really be defined here, because otherwise you are creating openings for external users to start passing their own crafted gfp flags and that feels wrong. Sure we can guard that down the road but we should not really need it. -- Oscar Salvador SUSE Labs