From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f50.google.com (mail-dl1-f50.google.com [74.125.82.50]) (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 4D16A31690E for ; Wed, 25 Feb 2026 21:56:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772056610; cv=none; b=aU/4vwtWzfZMKJva6kQ4ZGRmQV8qw1zfM5RYRdoc4eqzzSOXYqTNdXtH3vzc6JdpeEMY1Z6yS8uL2OiL++uVtu0nNK57N8eSpQ+AOkAQKpzAXiwP3/GfS9Iwh/jTT2M+c4rLY14FzjEciU69P6qjXqUTH/DBczrgVKMOsAe4RfI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772056610; c=relaxed/simple; bh=5NxL+lsmNkAmuod7M/UL2N/jLtE5LxxmzTX+fk4im1s=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FaPqSXdLQepbFkmiz+Yw9wQ0cQDO9qTqAN6Mz+aP6IrSJ+VBdTnUtPZ/GhVKToh2yf6lr/kBeQMIPU33Ak6jzybmFLnqF90sHCPs8zV5tA9EiYe/oCCPy3JGIXyHdDmG4mWk5F2VWif5sKr0zfbxKQ/34UbYX4kRYjREnR2B3cw= 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=OT2hRQA2; arc=none smtp.client-ip=74.125.82.50 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="OT2hRQA2" Received: by mail-dl1-f50.google.com with SMTP id a92af1059eb24-127380532eeso369777c88.1 for ; Wed, 25 Feb 2026 13:56:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772056608; x=1772661408; 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=hHyAmbqk7HhQ2rW+koNARPwcM5Pex8BM81YALg0B5qs=; b=OT2hRQA291/nG2QkcWyOho8mlXk+CqnF0gxuOpVFm5Q2PIwX/hUlJoIanT/V23TVoq iEBXskrmgix5NAUMwq1vb+/1cftb9+/1UH9dr4Bn5WZVTl0bCt92fQL5zC5Eh8zotnJo nhZHG+cLbcfspeinh8oXsLYAn2SI3LDi8h1Fh806/tye/FYykxIi8Ie3HjhBiyEi9r5L goiUiAY7NPY/OqpSLHXO0mJjrGIbWEW0sAnmVhpZjyJ4dObKzh83zknwZ0JqAJC5/ipW Yx9QBR1xloJQYppkuiYXTeJAujWzVwQZTrHcgwG+Bc/17fkLPWfSRcdPCkWjjmtWGwlY vZOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772056608; x=1772661408; 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=hHyAmbqk7HhQ2rW+koNARPwcM5Pex8BM81YALg0B5qs=; b=X6sXo1tMtO1F3hGVNdX5HMqGQkp22W2D2HuoCqIb/7nC5TAssUTr991RZpgmGQcaLf IDH561HnyI0nNzssam4LqIpgSIbIo3366DwcWjhzbWkbYO94HL1ANVAl7IL0shO1RcRa 3ERZdYZQJfLgb+cJDAPoh8twKznG47Wx6GtdtFgM0bhDqtufoblGrFV/rfAsGRTkbjNN MWG5ww1qrCEMujXaQb+NItaEIWr+vMWlC7RXdPdCc6PXq3OpP13u/n0+6VRofJhMiyhv aT8uIjClbSlXFom0kcK2+cl5UTsy8yEr/d9jQwp8rOgtxXr1k1uHDxAZ3/3K8MruSyzs A8tQ== X-Forwarded-Encrypted: i=1; AJvYcCVEc3/sv9QdK6i55QBsc13xITcvp3OHQ6OAiYyPb7HHmDt705fHatDaRjPr5ABa8a/n7wh3H98lenC8T70=@vger.kernel.org X-Gm-Message-State: AOJu0YwzWTXNHU8AHpW4eayymStnYluyyfzSDviXaaNU0XXgLcnMpVPx qTX1qgfYKP40I4D+0dP0TNqQX3cFba7Lp3rCfVNhV92jPh0xluoK4FU6bW69JA== X-Gm-Gg: ATEYQzwk4N3vqzpcTeqHkDtJTykcGu+0nSLjcvIA3QH8MKfgg6UR04bUXN1mfKiTeZA VhFCZI3a+P7A1pZG3DolBd9NVIP9VPy2/HfyT4T+iX8Jnkhx0Hf6RUuMxVJyi8QWJRLuVPB7iJq lWQpJ91gwwf6Yc+6ff5jSk2X+3sknMOe6zmBwvADRTfR0skXmlgqt811zFsI/lbV+Tn0WIOP2E6 CL62zRmbqX0UpG0kdyROh/Be9R/7i/i0NZseD/gK8grz7xHldp8otRctS0J3+3GMN5MhQO4g55d 6ePgX3Q8tEk3qiqkInqOoy0CtitWUTy99KhyJygt6ADvrCKeZnn8YiYVtDS9S5Iu9cpfrFRTySg KViLd8lOR7ZemOyAZMRq/Zbdn4LcPowe18/vHUi75OzL3rs8NPEqfN6H7+sy2Ogx8SAtWPNPNzf oY71y0mb53kiC2XC1JYNiA X-Received: by 2002:a05:6808:168b:b0:463:cf6b:982a with SMTP id 5614622812f47-4644622ce34mr8146359b6e.22.1772051111331; Wed, 25 Feb 2026 12:25:11 -0800 (PST) Received: from localhost ([2a03:2880:10ff:3::]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-4157cfa6624sm16078679fac.8.2026.02.25.12.25.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Feb 2026 12:25:10 -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: Wed, 25 Feb 2026 12:24:37 -0800 Message-ID: <20260225202437.4077364-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, 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. 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. > 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. 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. Thank you for the series, again. I hope you have a great day! Joshua > 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]. > > Independently of guest_memfd, I believe this change is useful in > simplifying alloc_hugetlb_folio(). alloc_hugetlb_folio() was so > coupled to a VMA that even HugeTLBfs allocates HugeTLB folios using a > pseudo-VMA. > > [1] https://lore.kernel.org/all/cover.1747264138.git.ackerleytng@google.com/T/ > [2] https://github.com/googleprodkernel/linux-cc/tree/wip-gmem-conversions-hugetlb-restructuring-12-08-25 > > Ackerley Tng (7): > mm: hugetlb: Consolidate interpretation of gbl_chg within > alloc_hugetlb_folio() > mm: hugetlb: Move mpol interpretation out of > alloc_buddy_hugetlb_folio_with_mpol() > mm: hugetlb: Move mpol interpretation out of > dequeue_hugetlb_folio_vma() > Revert "memcg/hugetlb: remove memcg hugetlb try-commit-cancel > protocol" > mm: hugetlb: Adopt memcg try-commit-cancel protocol > mm: memcontrol: Remove now-unused function mem_cgroup_charge_hugetlb > mm: hugetlb: Refactor out hugetlb_alloc_folio() > > include/linux/hugetlb.h | 11 ++ > include/linux/memcontrol.h | 21 +++- > mm/hugetlb.c | 228 +++++++++++++++++++++---------------- > mm/memcontrol.c | 77 ++++++++----- > 4 files changed, 212 insertions(+), 125 deletions(-) > > > base-commit: db9571a66156bfbc0273e66e5c77923869bda547 > -- > 2.53.0.310.g728cabbaf7-goog >