From nobody Sun Feb 8 18:48:14 2026 Received: from mail-qv1-f43.google.com (mail-qv1-f43.google.com [209.85.219.43]) (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 3F42E2848BA for ; Wed, 3 Dec 2025 06:30:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.43 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764743422; cv=none; b=jLTVOwwSxG8zdjKXWBpji50f4/tLMB87P9nsLczOL5AQsuw8SG9YfKl9InqqCNCWc2GBDHGVxu7DWHJCYCzJWStXpuxtan87zWtOtKFnoYu03bQc1c4epRsij35uE2bRsfhDDHGHAVsD5Bkv9U2QzgisTcuJwnC2o6JebgCGXdw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764743422; c=relaxed/simple; bh=ZmaIspEXMwBdXfjv08IdBm71D9jsdKqj9x2IAnZtq5M=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=SGUn+uqWJROmQP9SmOHHz4q4V7jvsLqcU6ts7MEvdLxJP0t3nY1D9fQz9/d/abpPm/iHL0CSevF+dSx+VAkDZVZYmSvMGPmb3J3HTOqrJS398P/zZVvVA/QiZ9nK/RFUO/zIrH7vEvBc/IZ23ZaqN7l35jMfwYMhgxV/criDL2c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net; spf=pass smtp.mailfrom=gourry.net; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b=PLn1CPE0; arc=none smtp.client-ip=209.85.219.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gourry.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b="PLn1CPE0" Received: by mail-qv1-f43.google.com with SMTP id 6a1803df08f44-8804f1bd6a7so51546256d6.2 for ; Tue, 02 Dec 2025 22:30:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1764743417; x=1765348217; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=zA8y4i15lHs4OWfRLesRXJafbhw/AjPpbVqRC57AGyo=; b=PLn1CPE0OMA3PHyUK7s2SYdE0/F5RFdl60goKsP45kCNruOUrrXToEAdVIxRXx3kAe eHLrrgVD5g9UuAl1JXKxmgNgMEkTH+7bocrg+RJrsYlEeEG1SuwWVfjt1C+bAdBUEnKv I1tPfrHwU0oq2Etbhwe2ZZj+VMKRasAzV8at95ekLHjssWymb4rP8ey2yyqYdw5jyJ1z ZL27w2P39MaDAfFsMswiw/p/msfDkYhVsmVuf+a4bnMm3hi8U0EGXOo7hCAG3d1chA5+ Khx0GBZMmbe/iIGWbPCGNA1k23iYhmuyjAgO3vFZ1SoMTAKrSqOxxNHlV3ZP1SCBE7nL 8DfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764743417; x=1765348217; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=zA8y4i15lHs4OWfRLesRXJafbhw/AjPpbVqRC57AGyo=; b=ZzsLsiG6c7p79NpAdOTM3+Qxy+vo9y8sL5UTbAxvwtqsvRSCLQ4vh0QfV1A1V8gswt 5tIH8RhUK+PehWhKBJpqWFXi/9YZi1PI5HuPgZJXRs+JzTPc/Fewj7e3Mzh4sks/py/W DJVbHSzV/DSa7lUxIqeexxP95U+kCzcjMjTudx8B0/9DhykjrsN0J9blzXgneqDcF9Fh oIiqkafn7RbrRxHDGUDnP0lb2ppphvxuI4sCvPYjjuo7dGiDTn6xIDqkeYNWhtluv0VO F5NAWjA2PiSYnO2DN7eBkp2fX4Rk/6uT5ofzS6tuO9H253XfJLi8y6AspjXqEFowYbS8 qgYg== X-Forwarded-Encrypted: i=1; AJvYcCXbQkFNxbbtb35b0xsYsWGZfN7W0h2yI7DtJz0plnsVx1ern/y16NgsA4VXMNpH+xiWeulOvIoBO3ynb5w=@vger.kernel.org X-Gm-Message-State: AOJu0YxeJrS6qpfDBod+n7hCDPB7dGyICbGI5tudBpcTsv0qOJCVhjBT HqmNOwGtoWpsBb8tkfrRKZJRGZDDPAL2t8/DOfTSOYUO1JVpbyoqWuSluey4Ul/TnCY= X-Gm-Gg: ASbGncsPdyeFNcKW82784bMcalsWj11OmHxjAfjmmwpoR4rvK/FsEPUlLo57ekCXnx+ 2BzFpDrnSs1sOqmn2YCr8YbueEbHTj2k35+QIa9q6r6vtCdnmQqJoMlEpNtg70qpm9yk4PjZwOm 1pkfVoHyrAvJtfy6hR6ruqx+f5WWwHjlTR6EzqkVbAeRtsaulNXXxeRNsDqGImbZt336LT5VnGw 5tx2WCX88eaAf4WzI0dMH307wTyhD+7vID1RviBmavBL9nMQeHEbBa0pTrvjXcZaY5KEjzvsc1x 4WslrEFKYlEX3stjpzWq6V4Xspmi4juSZ8fbb1pDz33uEyTXs6sYA6gGoqf0TGEtZnyCrrTSUeB ObXEWgykWlUefEl/znZwkIqtuyn8YnwyqU2f/hJ3E4ZCLV0DifKSpJKgTB8H41NVT30DcQTpsDp n41VIRRxomIU/LXAF/73yrkPLPEFOoknOU+xeTqd6Kob2gmTHb8xVakPlDELEztwB/zr0bRgx53 Htq6PmN41XMbQ== X-Google-Smtp-Source: AGHT+IF1GdXPSabAZHw0YMxptT9SRN1HvIpeNLe4gzMuYc6tHsW25MPHAsf8Dnnhll6yIyHsxXJH7w== X-Received: by 2002:a05:6214:d0c:b0:880:5867:45b4 with SMTP id 6a1803df08f44-8881949a8b6mr16086076d6.13.1764743417043; Tue, 02 Dec 2025 22:30:17 -0800 (PST) Received: from gourry-fedora-PF4VCD3F.lan (pool-96-255-20-138.washdc.ftas.verizon.net. [96.255.20.138]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-886524e4b15sm119791806d6.15.2025.12.02.22.30.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Dec 2025 22:30:16 -0800 (PST) From: Gregory Price To: linux-mm@kvack.org Cc: kernel-team@meta.com, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, vbabka@suse.cz, surenb@google.com, mhocko@suse.com, jackmanb@google.com, hannes@cmpxchg.org, ziy@nvidia.com, kas@kernel.org, dave.hansen@linux.intel.com, rick.p.edgecombe@intel.com, muchun.song@linux.dev, osalvador@suse.de, david@redhat.com, x86@kernel.org, linux-coco@lists.linux.dev, kvm@vger.kernel.org, Wei Yang , David Rientjes , Joshua Hahn Subject: [PATCH v4] page_alloc: allow migration of smaller hugepages during contig_alloc Date: Wed, 3 Dec 2025 01:30:04 -0500 Message-ID: <20251203063004.185182-1-gourry@gourry.net> X-Mailer: git-send-email 2.52.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" We presently skip regions with hugepages entirely when trying to do contiguous page allocation. This will cause otherwise-movable 2MB HugeTLB pages to be considered unmovable, and will make 1GB hugepages more difficult to allocate on systems utilizing both. Instead, if hugepage migration is enabled, consider regions with hugepages smaller than the target contiguous allocation request as valid targets for allocation. isolate_migrate_pages_block() has similar logic, and the hugetlb code does a migratable check in folio_isolate_hugetlb() during isolation. So the code servicing the subsequent allocaiton and migration already supports this exact use case (it's just unreachable). To test, allocate a bunch of 2MB HugeTLB pages (in this case 48GB) and then attempt to allocate some 1G HugeTLB pages (in this case 4GB) (Scale to your machine's memory capacity). echo 24576 > .../hugepages-2048kB/nr_hugepages echo 4 > .../hugepages-1048576kB/nr_hugepages Prior to this patch, the 1GB page allocation can fail if no contiguous 1GB pages remain. After this patch, the kernel will try to move 2MB pages and successfully allocate the 1GB pages (assuming overall sufficient memory is available). folio_alloc_gigantic() is the primary user of alloc_contig_pages(), other users are debug or init-time allocations and largely unaffected. - ppc/memtrace is a debugfs interface - x86/tdx memory allocation occurs once on module-init - kfence/core happens once on module (late) init - THP uses it in debug_vm_pgtable_alloc_huge_page at __init time Suggested-by: David Hildenbrand Link: https://lore.kernel.org/linux-mm/6fe3562d-49b2-4975-aa86-e139c535ad00= @redhat.com/ Signed-off-by: Gregory Price Reviewed-by: Zi Yan Reviewed-by: Wei Yang Reviewed-by: Oscar Salvador Acked-by: David Rientjes Acked-by: David Hildenbrand Tested-by: Joshua Hahn --- mm/page_alloc.c | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 95d8b812efd0..8ca3273f734a 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -7069,8 +7069,27 @@ static bool pfn_range_valid_contig(struct zone *z, u= nsigned long start_pfn, if (PageReserved(page)) return false; =20 - if (PageHuge(page)) - return false; + /* + * Only consider ranges containing hugepages if those pages are + * smaller than the requested contiguous region. e.g.: + * Move 2MB pages to free up a 1GB range. + * Don't move 1GB pages to free up a 2MB range. + * + * This makes contiguous allocation more reliable if multiple + * hugepage sizes are used without causing needless movement. + */ + if (PageHuge(page)) { + unsigned int order; + + if (!IS_ENABLED(CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION)) + return false; + + page =3D compound_head(page); + order =3D compound_order(page); + if ((order >=3D MAX_FOLIO_ORDER) || + (nr_pages <=3D (1 << order))) + return false; + } } return true; } --=20 2.52.0