From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f52.google.com (mail-ot1-f52.google.com [209.85.210.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AA5F03603F6 for ; Thu, 26 Feb 2026 18:08:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772129308; cv=none; b=i6KYnxju2NdfKE8mv0cs/Q+ySoIhcEWXUSPkVvFPTy8RH6yT4IW8gVtODbiS3kWcs4khq4iIH7niWklqHHLtxyik65wA3hT0y+rC/AXGrgPcWyCRCb4Y97Sm1kmZY5BQBhBpH+QSImHoV/O6BCNoNapmDDDfKCGwQCRDkNLE8W8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772129308; c=relaxed/simple; bh=XrT6+F4L/RdfSwyg3Ac65ntxz3H2SsHPU5uO2O7bnKU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qKr1FAmLYLvVQzxwAUIFmDE7aZtdzhR28V4kOIWZtqDy9ll4cSM+6mSsgdkDUFQ+UmjRk6EHD06vVWXItJxOePk/HnxcDea+i/rziP60hwFgRam6qO5xEadF6iLgsE9HDktFRVffOj+rGKv2VrSKa1tsC4eNUZvIX/87dOhgQN8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=J/dllCtX; arc=none smtp.client-ip=209.85.210.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="J/dllCtX" Received: by mail-ot1-f52.google.com with SMTP id 46e09a7af769-7d18a9d2b1aso1259553a34.2 for ; Thu, 26 Feb 2026 10:08:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772129303; x=1772734103; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=wcq9MDR3n757j4ORZwFr28h6INReHt+LZDRBVW4SzF0=; b=J/dllCtXpL1DPs0TPWfxlx9LUW6VL0zoQx54nbCMchOg3/T83WmHxF9u/v2X+NOYFQ n5pn50xOxhOPAtLIdLwHPqBUPsfnrEMTj7MJLteJgmEE2Rn0uTiGuIf/vjRHxB+deW2S qK8IuOxznSsB+ZSffjU03JuEAuibwsr6NTPKp4FDVjtTlrdBAKcmDhGYD7et25m6FWZR Ne91mt8D415tHsqsa5Bv9Jl9P38G0z/z0jA16SoevmSp3tyuHT2iAsCB1/SBCW4WDLki Kzdq0rl7F1lEtHAJw9H0Buqxw432wpvRAs0PcnhBS4hKtpXLouLRF9x55W2ItRiNYu4+ oUSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772129303; x=1772734103; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=wcq9MDR3n757j4ORZwFr28h6INReHt+LZDRBVW4SzF0=; b=w1Oujnh/T9/oKMHyzgImnY35obw30t6ijsqgr4djLEi5X0YccAmAIhlG0SRwgLE2Gh +E+q8+6mswgRlpMnhVeRrzqJwMvPyLE476ofHMQ9OiCpBtRQ5tHh08c5mQDDp5kDsZ8X jP9PidHgL9DWhtzgl78CNKte3s15NFNAELRmz6rUmUPsYQZ+Csc6Cy/WmwtzgvDzJnqb vvvHQ0wcT/7RJpiZcpn04xWwGiLOoZoqY+XqRnqP0o565MRKpSIzMXCzxNd+ft9REIsh Uu4prUtsqGrGTTZdf1GFQmJcJyR3xp+owqvmWvsFsim/sdIR3jwQ9378Z6M1usmeQSKV Q38A== X-Forwarded-Encrypted: i=1; AJvYcCVFct6NF/G4zmk/oEenhYjZYnAYYqle+lEK14G0fDnqGR/SWkDYviJqTPVepu7jovapFkeCyn1LlI+XKeE=@vger.kernel.org X-Gm-Message-State: AOJu0YyMT6kcAEMRTZYLGTm5ChhgNY9wdKRUGKRMjtbGdJxQylA+US4P BPULHz6JMknaDFvDT13/7P3VV3ljiyaeov35lKdZ8K1+eeR2lJ4fVyYY X-Gm-Gg: ATEYQzxVdu9pvJ31awSDhwG0fOVcMsaqP6e0oalE0UpEZJy6066HBduCivPBaJLxmYB PxfkFaJaUdco9VVmC9I8Ci37SAj5xBUMNb4Sf7lF3rJ7Wc+2i9tNr5jeUnbdXSLr/HghcbWPyUz S5b9Huboimy76wa3nov/63jU9FKLVM+1KPft88UNbcintvKTGPgf/RmTVvmi/N4Az1UJN//5Qmn iRfgHJIiDL2GEMWiQVVAld2qA1S5C+vd+9ulAA2Zhd/tWN5kHzyoEAj+VjAZ4KwGXfso/Mm/uhP 7js7QeYx7c4cSRiIPchgVXC2AvmhxDxSRXcJJ/wLX62M6VOjVdedXYKzaWlRwTYZQP2HQ5ZbTNc FcL7Pp5nBV3a8IYq0wGVEU4s8CJPj9d5CZEJuqeeD2s+Y8RvqbZHaizaY4crfJiEzK6l3PoLYYK Qjtwh3LoI2UtL0MDy/Yn+/H4Gq4A0icmbX X-Received: by 2002:a05:6830:6201:b0:7d4:96c3:3f97 with SMTP id 46e09a7af769-7d591b0f5acmr73197a34.2.1772129303538; Thu, 26 Feb 2026 10:08:23 -0800 (PST) Received: from localhost ([2a03:2880:10ff:70::]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7d58666ed17sm2433431a34.27.2026.02.26.10.08.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Feb 2026 10:08:23 -0800 (PST) From: Joshua Hahn To: Ackerley Tng Cc: akpm@linux-foundation.org, dan.j.williams@intel.com, david@kernel.org, fvdl@google.com, hannes@cmpxchg.org, jgg@nvidia.com, jiaqiyan@google.com, jthoughton@google.com, kalyazin@amazon.com, mhocko@kernel.org, michael.roth@amd.com, muchun.song@linux.dev, osalvador@suse.de, 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, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC PATCH v1 0/7] Open HugeTLB allocation routine for more generic use Date: Thu, 26 Feb 2026 10:08:21 -0800 Message-ID: <20260226180821.2218448-1-joshua.hahnjy@gmail.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Wed, 25 Feb 2026 19:37:04 -0800 Ackerley Tng wrote: > Joshua Hahn writes: > > > On Wed, 11 Feb 2026 16:37:11 -0800 Ackerley Tng wrote: > > > > Hi Ackerly, I hope you're donig well! > > > > [...snip...] > > > >> I would like to get feedback on: > >> > >> 1. Opening up HugeTLB's allocation for more generic use > > > > I'm not entirely familiar with guest_memfd, so pleae excuse my ignorance > > if I'm missing anything obvious. > > Happy to take questions! Thank you for your thoughts and reviews! Of course, thank you for your work, Ackerley! > > But I'm wondering what hugeTLB offers > > that other hugepage solutions cannot offer for guest_memfd, if the > > goal of this series is to decouple it from hugeTLBfs. > > > > The one other huge page source that we've explored is THP pages from the > buddy allocator. Compared to HugeTLB, huge pages from the buddy > allocator > > + Has a maximum size of 2M > + Does not guarantee huge pages the way HugeTLB does - HugeTLB pages are > allocated at boot, and guest_memfd can reserve pages at guest_memfd > creation time. > + Allocation of HugeTLB pages is also really fast, it's just dequeuing > from a preallocated pool All of these make sense. Just wanted to know if guest_memfd had any unique usecases for hugeTLB that normal hugetlbfs didn't have. > The last reason to use HugeTLB is not because of any inherent advantage > of using HugeTLB over other sources of huge pages, but for > administrative/scheduling purposes: > > Given that existing non-guest_memfd workloads are already using > HugeTLB, for optimal scheduling, machine memory is already carved up > in HugeTLB pages for these workloads. Workloads that require using > guest_memfd (like Confidential VMs) must also use HugeTLB to > participate in optimial workload scheduling across machines. > > >> 2. Reverting and re-adopting the try-commit-cancel protocol for memory > >> charging > > > > On the second point, I am wondering if reintroducing the try-commit-cancel > > protocol is tied to factoring out hugetlb_alloc_folio. When I removed > > the protocol a while back, the justification was that for the most part, > > grabbing a hugetlb folio was a relatively cheap & fast operation, since > > hugetlb mostly operates out of a preallocated pool. > > > > So the cost of being wrong, going above the limit, and having to return > > the hugetlb folio was also relatively low. > > > > Thanks for this! I saw your patch to just optimistically grab a HugeTLB > page :) For that patch, the primary reason was to simplify the logic, > and the simplification was justifiable because grabbing a folio is > cheap, right? (And so grabbing a folio being cheap wasn't a reason in > itself?) Yes, exactly! > > It seems like this patch series introduces some new paths for hugetlb > > pages to be consumed (specifically, without a reservation or vma). > > I imagine that these new paths make the slowpath for hugetlb more frequent, > > which makes the cost of assuming that the memcg limit is OK higher? > > I think explicitly spelling this out in the justification for reintroducing > > the charging protocol could be helpful. > > > > Yes, I should have done that. Will copy the following to the next > revision. Thank you for considering! > The main reason is that reintroducing the charging protocol is the > clearest way (for me) to cleanly refactor out hugetlb_alloc_folio() > without worrying about the edge cases around HugeTLB reservations and > charging. > > If I didn't reintroduce the charging protocol, I would have to depend on > freeing the new hugetlb folio on memcg charging failure, and the freeing > in turn depends on the subpool correctly being set in the folio, and the > presence of the subpool influences (in free_huge_folio()) whether the > reservation was returned to the global hstate. Aaannnd... there's also a > hugetlb_restore_reserve flag that controls whether to return the folio > to the subpool (and the hstate). I find folio_clear_hugetlb_restore_reserve() > on certain code paths kind of magical/unexplained too. I see, if it makes the code simpler to introduce the protocol again, I see no reason why we shouldn't revert the patch : -) > I would rather iron out those charging and reservation details > separately from this series (with more testing support). > > On the other hand, reintroducing the charging protocol has the benefit > of avoiding allocations (not just dequeuing, if surplus HugeTLB pages > are required) if the memcg limit is hit. Also, if the original reason > for removing the protocol was to simplify the code, refactoring out > hugetlb_alloc_folio() also simplifies the code, and I think it's > actually nice that memcg charging is done the same way as the other two > (h_cg and h_cg_rsvd charging). After hugetlb_alloc_folio() is refactored > out, the gotos make all three charging systems consistent and symmetric, > which I think is nice to have :) > > I hope the consistent/symmetric charging among all 3 systems is welcome, > what do you think? For the hugetlbfs case, the path to allocate a hugeTLB page on demand makes sense, so I definitely see the argument for avoiding allocations. Does guest_memfd also have a path to allocate a hugeTLB page outside of the boottime reservations? In that case I think it would be nice to clarify that the allocation failure case optimization is also for guest_memfd, not only for hugetlbfs. Symmetric charging is definitely welcome : -) All of your reasons make sense to me, I just wanted to ask and make sure. Thanks for your thoughts! I hope you have a great day!! Joshua