From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f202.google.com (mail-pf1-f202.google.com [209.85.210.202]) (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 320AA38F9C for ; Thu, 12 Feb 2026 00:37:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770856648; cv=none; b=FQzhQsq0MJo0KVOyxgiwj4JqpdJ6bw10yMrHtZx/aZGKccV1vW8Kt8rI5sC3BrwTgZ9HEeSo9J1VgxrY5p01KAKpz1WUC8SM7ZFBcnIym8LJzWaw3pS2KChz+SxBiXSaXcMlH5LsbPSbXOcpQYiAgy6GemshzpJcU+E1POQm8RM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770856648; c=relaxed/simple; bh=9WTi6KAC0+HthWewv6tioKPF1lEUgA9a4VwO5mmLJn4=; h=Date:Mime-Version:Message-ID:Subject:From:To:Cc:Content-Type; b=HJdgSCR7n0rp6abwI4IBRQwlPJbZVJ3A4dgAXcfgQDBJvdOdG/5ep3sEhgileKSoNYmXOof88mqjYxR70Z79g/0zq2s2VZZ0RuKrSnQ4WiJvnBqRapZ30xi/wBYvZkscB2w/sb2+kf/4ApMlacA9+UFJimBiHoXcYbkC2bG1aGI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--ackerleytng.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=Bflo7ZBi; arc=none smtp.client-ip=209.85.210.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--ackerleytng.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Bflo7ZBi" Received: by mail-pf1-f202.google.com with SMTP id d2e1a72fcca58-824a0ea2025so467409b3a.3 for ; Wed, 11 Feb 2026 16:37:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1770856646; x=1771461446; darn=vger.kernel.org; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=ZJpTlhiR4TRyjHrLxyY5K7IcESbEG+rqURvXdu9Kbh4=; b=Bflo7ZBi+oTruw92NTznVg+QPwuYMHL3v8GJwLvULFQ+Tltta9pHScczIR98PiFIHX eEA7COTGy0bZsjF4Fq0D1IVGjJ26gIXbrH0Xw5uA2bddVWCpWc+6F1l/UVNsT0o0vh/P i3Tv6sL8iauQ8jp7PwwyKFQrmMgjNK8VaIN/4bJ0vriK0sn4OjGonEVn25dmnE/I0Grf OjjsVhYz7G2SuUeLkZQfBOUWU4rnc9gcsUXM8lUNTnGSoB78llZoEXVClp2eNH8MJoHx lpZEqw2AagyOfCV8o4bwiS8VYIabzQexRf3p9J3LtKYS12LCPRNUm3dC5PAfm7lht9NT ShKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770856646; x=1771461446; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=ZJpTlhiR4TRyjHrLxyY5K7IcESbEG+rqURvXdu9Kbh4=; b=J/WVahfaRGk0ITj9kMYdufj+rcSF5aKrYLjXzGSdgRxkMI0bXzuCHhbhsgkFvlmSAP EK0nANgyl7sx//ZSrwfUt5xkfjBjgZXEavsEOAsGre3y0KZZ648vQWKabYZjXiRIU88i eMIM3tHAuWcavIIPLpOHAFtWBUk+U79ru24+bJrtj+K5DWOdN06z5KYV9/KV22gY7HpS MEIfrzXhMrHYZ6ALQG7TVL3Xpeo7UnCG3RBoSiO/Ieci4cifOU2FMd+/5sG/zV7aJ2xU +caL4wDxSZPH4cHe6KvMNHZ5oQXhjSGPy5iBELlRy4W57/13ebW7rY3jnNQ1BljUm2Hy c3DQ== X-Forwarded-Encrypted: i=1; AJvYcCXjbA4cAd27GxXYqtSRdptjw+BBocUdyieJWfWtFAFyddtQnAZycER05NpGYh5K9pavSKx3GpgHnIQESvI=@vger.kernel.org X-Gm-Message-State: AOJu0Yy1RTX99213qgzCwmuc8FcfpMAv3RS38xZWI17uwlYQmdJnV/1q 6pvG35Lt1bo2ug8LBhlIMzxCkKTU/nou34d4pRvsJMpd8z1BYi/W51UVkhM/wv7aaPWOuTDpm3u mB2HZyVNXCRJpADkhu0je2jBpEA== X-Received: from pfbih24.prod.google.com ([2002:a05:6a00:8c18:b0:824:b235:888c]) (user=ackerleytng job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:2492:b0:821:8230:235d with SMTP id d2e1a72fcca58-824b04e5834mr661593b3a.39.1770856646414; Wed, 11 Feb 2026 16:37:26 -0800 (PST) Date: Wed, 11 Feb 2026 16:37:11 -0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-Mailer: git-send-email 2.53.0.310.g728cabbaf7-goog Message-ID: Subject: [RFC PATCH v1 0/7] Open HugeTLB allocation routine for more generic use From: Ackerley Tng To: 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 Cc: ackerleytng@google.com, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" 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. I would like to get feedback on: 1. Opening up HugeTLB's allocation for more generic use 2. Reverting and re-adopting the try-commit-cancel protocol for memory charging 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