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 ED9A33845DC for ; Mon, 18 May 2026 04:49:32 +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=1779079773; cv=none; b=CQPdMVZWDC+Yjswp/aIHY3qoaSpSPdyzKtyl4h2JEz6bAzrgHhzXCRo/CP2FsQpHEOWJYXQp91G1Uv12EyT1ypowxFPH5v0pitDM7Y7Gee2/7MbhM6QG5RJKhV7e++tyYeLmHAs+KUBbYVkwHXQH77uUtNL64xWYv8bNvjlIDr0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779079773; c=relaxed/simple; bh=ddstMBPXuzDhxfV/zDKcv0EX+9y5aSk2ybQr7szpmtM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=QsDyEbIsqtY1ODjYovPvi82M315TylhAo4yMONYjQIURVHI6bfHjGhb7pchBK0qmybk0AVhEdOZVMY5Otw/NciF8+5phNXwhlGIEuoz9rAW8CrvwVRC5MB8LNPhtInnYsEGtiK8Yt4rZ+Gie3rQIu38T524+GI8fas9QpAhFP2Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=XBqhwp3b; 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="XBqhwp3b" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D8904C2BCB7; Mon, 18 May 2026 04:49:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1779079772; bh=ddstMBPXuzDhxfV/zDKcv0EX+9y5aSk2ybQr7szpmtM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XBqhwp3b7Or4r/oRklsbjLwMjXxsLdQgLNlYK0lwHjMBOcSzGuoQxnwVC/xpdMPeq x/4wlWaU/A0cjtalw9ozh56yn4OvDdStyEHMT6man46ypwbbrvwsOXEQRqp3Mvy3Qo i8DJHWtYJywJ+TE+O1UmGmfuISFLVitgTozeGtQJSiWXJIfU1lcd8oqfHYw35VYZjW hujdecs86StuFxrbYc4XihS2/4uIwGHypyn25uoVIs0VDS4fuqwkFK2W1ncnO+8IoC 7om0UafwM8b6WPLg5BzF1Jo0W9DhzRafpCw4IeHuRUVybrM0S73Z4bg0bBLh9k09KR 1GTkHs3joleTw== Date: Mon, 18 May 2026 06:49:21 +0200 From: "Oscar Salvador (SUSE)" To: Oscar Salvador Cc: ackerleytng@google.com, Muchun Song , 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, Dan Williams , Jason Gunthorpe , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 6/6] mm: hugetlb: Refactor out hugetlb_alloc_folio() Message-ID: References: <20260506-hugetlb-open-up-v2-0-826a0c5f28fc@google.com> <20260506-hugetlb-open-up-v2-6-826a0c5f28fc@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: On Tue, May 12, 2026 at 03:25:30PM +0200, Oscar Salvador wrote: > On Wed, May 06, 2026 at 08:54:42AM -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. > > > > No functional change intended. > > > > Signed-off-by: Ackerley Tng > > I yet have to review more thoroughly, but I have a comment below: So, I thought about this some more and here it is what I came up with - Ideally this new hugetlb_alloc_folio() function should be as generic as possible to try to fit other users in the future - I would create a ctxt struct to pass all the parameters - charge_hugetlb_cgroup_rsvd and use_global_reservation could be a flags thing (action_flags?) within the ctxt struct. We might want to add more flags in the future to tweak the allocator behaviour. - Ideally gfp_t mask should be created in hugetlb_alloc_folio() and tweak it in there before being passed down the road, which means do gfp_t gfp = gfp_mask & ~(__GFP_DIRECT_RECLAIM | __GFP_NOFAIL) in hugetlb_alloc_folio() instead of doing it in alloc_buddy_hugetlb_folio_with_mpol() As of right now, we define it in four different places: hugetlb_alloc_folio, alloc_hugetlb_folio, dequeue_hugetlb_folio_with_mpol, and alloc_buddy_hugetlb_folio_with_mpol. - I think we could strip _mpol from both alloc_buddy_hugetlb_folio_with_mpol and dequeue_hugetlb_folio_with_mpol, and pass a boolean "node_preferred_many". I am probably missing something but I cannot remember it right now. -- Oscar Salvador SUSE Labs