From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (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 4B63D3E9F76 for ; Wed, 20 May 2026 15:00:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=96.67.55.147 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779289238; cv=none; b=pqVRHvD4gs4zc5oLatQn2dhgM38EwTjBDqsWyFChRDYYQmZPDTgAO4VOq9UbX8OYcKiFAcmNQk4pEL3g9AHqZR6i+l4ssShUs2T5wxBtw38XsCh+pxRG2wgQjhLxSbH3em/NSpIT9oW+ncGHPnuYDuOBdZ9I3C2dqLotUfpdkjU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779289238; c=relaxed/simple; bh=4Br32lBLiNC8Vqe5MSZhXwOr+jDRg+CT3hdngqVKlfo=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=tba0fsrEQOx+A53X9pvnmT3T4VuewabdGhKbCsOdEuOxl6Yr6YZzk47a8P0p7+0T0USLeM9aPVZKrXjLqL6IG8KKItFbprHvWnideMr63z5RvAn+sssYY2dOVC60Ll/f3DzLVOYo8ASGPeH/XEzfenS71qYFJMhTJfzI7cJ4j98= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=surriel.com; spf=pass smtp.mailfrom=surriel.com; dkim=pass (2048-bit key) header.d=surriel.com header.i=@surriel.com header.b=YTqwMpxe; arc=none smtp.client-ip=96.67.55.147 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=surriel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=surriel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=surriel.com header.i=@surriel.com header.b="YTqwMpxe" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=surriel.com ; s=mail; h=Content-Transfer-Encoding:MIME-Version:Message-ID:Date:Subject:Cc :To:From:Sender:Reply-To:Content-Type:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=SJ/E0h+Jcau1sfPZwCYkdaMr3K0ldTX3IQaBiW/wOI8=; b=YTqwMpxeHkLxwIa72X/SVb1fw1 NwjjyLqp7bh32LeqsIPUeJfpnD3G9kNFS2kL/2d1tM+YG16BhnxrGIxD9FYlFwqxThgEB++Lj38+G uvD8KuChHiOjCjNG0nu2QeiuSjTluA683c9bc2BCMUtdnOwswCZ1JwQeONjo0G/IxJhV/2fvIfaYV N1NXqOYV7q7WyG+y0nKyiZP0JvV8PJ+lYEfhuJxESHPRUdxu8wG1nAQ1m6cYNzpCzWUEzXmPyMWkS Lk51DpVVsw0FySXleWLplnr0SD+TJ7WlitRGxwUoBkWnaygESRLUgSfIW+Jul2Ua/FrmYydqZ5jS8 IfHPYvfA==; Received: from fangorn.home.surriel.com ([10.0.13.7]) by shelob.surriel.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1wPiPM-0000000024Q-011W; Wed, 20 May 2026 11:00:28 -0400 From: Rik van Riel To: linux-kernel@vger.kernel.org Cc: kernel-team@meta.com, linux-mm@kvack.org, david@kernel.org, willy@infradead.org, surenb@google.com, hannes@cmpxchg.org, ljs@kernel.org, ziy@nvidia.com, usama.arif@linux.dev, fvdl@google.com Subject: [RFC PATCH 00/40] mm: reliable 1GB page allocation Date: Wed, 20 May 2026 10:59:06 -0400 Message-ID: <20260520150018.2491267-1-riel@surriel.com> X-Mailer: git-send-email 2.54.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Some workloads see real performance benefits from using 1GB pages, but allocating 1GB pages has often been limited to hugetlb pages that were set aside at boot time, or using CMA to keep a fixed amount of system memory off limits to the kernel. Neither of those are great solutions, given that modern servers tend to be large, often run multiple workloads simultaneously, and each workload wants something else. To address that issue, this patch series divides memory not just into 2MB page blocks, but into PUD sized superpageblocks, and aggressively tries to steer unmovable, reclaimable, and highatomic allocations into those superpageblocks that have already been "tainted" by such allocations. The goal is to leave as many 1GB superpageblocks as possible used by only movable allocations, so they can be easily defragmented for either regular PMD sized huge pages, or for PUD sized huge pages. Various strategies are used to accomplish this goal: - unmovable and reclaimable allocations are preferentially done from 1GB blocks that have already been "tainted" by these allocations - kernel allocations that can be done as one higher order allocation, or a number of smaller allocations (eg. kvmalloc) will fall back to small pages, rather than taint a new 1GB block - movable allocations are preferentially done from clean 1GB blocks, which have only free and movable memory inside, starting with the fullest of these 1GB blocks - 2MB allocations follow the same strategy - 1GB allocations start with the emptiest clean 1GB block - if a 1GB block is mixed, with some movable pageblocks, some free pageblocks, and some unmovable/reclaimable pageblocks, the system has a free threshold below which only unmovable and reclaimable allocations can be done from that 1GB block - below that threshold, no new movable allocations are allowed in that 1GB block, while new unmovable/reclaimable allocations are still allowed - when a 1GB block is below that threshold, use the migration code to evacuate enough movable memory from the 1GB block to bring free memory in that 1GB block back to the threshold These strategies together serve to concentrate unmovable and reclaimable allocations in as few 1GB blocks as possible, leaving as many 1GB blocks as possible available for movable allocations. That enables both more extensive use of 2MB THPs and mTHPs, as well as reliable allocation of 1GB pages. The above strategies also make the core page allocator more complicated, and slower. In order to avoid that issue, the series is built on top of Johannes's PCPBuddy series, which has the goal of reducing how often CPUs need to get pages from the zone free lists, instead relying on CPUs giving back pages to each other, based on page block ownership. TODO: - compaction "always" succeeds, with a success rate of 99.96% seen in traces; this sounds great, but it also results in compaction never being throttled, and compaction blowing out everybody's PCP through lru_add_drain() calls. This needs some sort of solution. - replace the superpageblock name with something Matthew and David both like - find more corner cases, and fix them Based on e1914add2799