From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) (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 C34712D949C for ; Fri, 19 Jun 2026 04:41:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781844095; cv=none; b=tJLetO/Korg9CIdsDes1VqEdWCc63Kg1ND50CpjxNHSp4IyttFIZlTf4fmiWwCOnPR7g2CSyL3a9TnhYlHNQ7X6q50RvfraWMlYB3jFgTjj8g71lwEuoTWO2T+40QTPkDEmE+d74OUdSk39HJLpsBPCUhbkIYNFezOiVDJqUaRc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781844095; c=relaxed/simple; bh=Q+9pcS/pBPiF1oPivDHV9NFFwG8jSo9lvD/DEY4Gbz8=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=iOfBJFhIb2ziX50NSjt89+A5u+27Q+z9FXxW2+SgNgfFO1CqzQAv/mhKuonpxJOmKZHGlwcfRRrF3H88yo3zfkylCPq72IsZPN3gh4kJox6P2nobbFuNQIHMem2BvUINx8p9/ToDbZyPu2jFoaucspziTnnXKsEeMkTCbeVt3II= 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=GRjS77AW; arc=none smtp.client-ip=209.85.214.181 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="GRjS77AW" Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-2c0aa420401so10811675ad.3 for ; Thu, 18 Jun 2026 21:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781844092; x=1782448892; 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=ScGPgP09d6CTH8k9i/xxOIHmej0/0GzUcvmFJcghR1c=; b=GRjS77AW7xlpZnKEMqtUtnSzZ92QpZzfnHJzExlWKZMQcveLMvwQMEb1RPLl0PWDzl Qkg2ZD12+wXgUZ3ylpcW4BvcJ3Rm7FkrQtf1TYpCpHH71Th/EG6d4p0qP9+f7T6B+XU3 ecXSg1/SuYyxZraUbPX9knHX2bwBC2pLx/fGa9XEyxFaR2bm7RzCL+MiTcqxJP2xumXc wmsMvlp22j2gBzgQ1nkMgcMlmO/9000Sq3jgejN79eukgBe2To2aJOGDMxXXoUQMZOg4 T46Tmu+TIfqXM5lK3b4zX6wVEF49rLvN/OtlXRbvZxOgFaCpIc5DspMC+uluJ0s7xP3G P+Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781844092; x=1782448892; 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=ScGPgP09d6CTH8k9i/xxOIHmej0/0GzUcvmFJcghR1c=; b=JQFrOrcX3yMhsM6oVYVAkIqGhyToWpHVImll528TKgYQISkYKBbnjs+zY2sqH/ynWD V8viYn3oIPNTkbNWGYIvIcDQqfxXeoBrllf958k40Hl2ILVK5dOwfS6CBKcfcrVGXI4n VPgwzRpVjNcc6cYbI0aq8E3dqaE2xtiWzNgoEaPgrMwhsKPv+pZHGq/8MIOv2ouirbvI t35XDS/beJYC20a+PnF7mar+RQIcMLy2Yr1OnJfZ+w9GqNeShBQZD6NAaJprEvseMUEz 6i4leRB3ZeTEUs9m8OgO3XdjkDWhKSZqx+2Usqrv8cLxsdXhQb/HFLM4tRBGc66eOipo NC3A== X-Forwarded-Encrypted: i=1; AFNElJ+CT45A2DzrW8CifRhrxvK5MCWMaAHw2bCmsuYzGZ6/IHfE69sQFJT4TV7jDuTCXK7QdblVxofpHns09sI=@vger.kernel.org X-Gm-Message-State: AOJu0Yy0oy5l1EDcPbkZkEtxhYJoXp89CcdGr1to+49pJUclg53qYBQ4 lq/GTmNPI/EB+UQ9zyYMndzOs5zaGHC82oHa/NR5JPA4p9c9xT3xv6XS X-Gm-Gg: AfdE7ckfEcMJ/wCIIXKB+NBRfEtkDOF5WNcXm9ppm9B/5QhBzBSZXtEQVn02qvicHAt y7DJCnVvaJQ53BcUoMZ7No8RYDOWCDSaa8E6zHDukz669XrnZhmD+1D4DjmM842/EMNO5sTas4U 4d1AnBCEaQytKvBL2eALsyTPKVtan9nlv31oLg/a7yt/FDmaU2iRLYjJd54jc4QaJ882iiYacPU lNM7mF9Hn6dPRkk1ME//hcMImvY3qex8FAV3rmoo6aoqfLlGhxzbsvuwlyVJFZ/0XJMetwyald2 0Ky7VkfoMaYRFQyjXUKyn+r2W6kLLUWBda0Q0Ys8jyidAnOz+Gj2V2CwrWoaGWp0vQOEoDg/YSt lj6pmHXqWYvdYZloR0cldUGKBBzs0Qakirae3ghmXVF+zYANc7OgSWTuOYretkfbULuIpSmkUAo VYqjaT7zl2H4NJahxxdDwPpg== X-Received: by 2002:a17:903:2b0b:b0:2bf:dd8b:7cd with SMTP id d9443c01a7336-2c725b713c9mr13974385ad.10.1781844092067; Thu, 18 Jun 2026 21:41:32 -0700 (PDT) Received: from pve-server.rlab ([49.205.216.49]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2c7208e5760sm8293735ad.36.2026.06.18.21.41.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Jun 2026 21:41:31 -0700 (PDT) From: "Ritesh Harjani (IBM)" To: linux-mm@kvack.org Cc: Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Andrew Morton , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Baoquan He , Barry Song , Youngjun Park , David Hildenbrand , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Sayali Patil , "Ritesh Harjani (IBM)" Subject: [PATCH v4 2/3] mm, swap: allow archs to override SWAP_NR_ORDERS via ARCH_MAX_PMD_ORDER Date: Fri, 19 Jun 2026 10:10:58 +0530 Message-Id: X-Mailer: git-send-email 2.39.5 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 SWAP_NR_ORDERS sizes a few small bounded arrays inside THP swap allocator code (nofull/frag cluster lists, percpu_swap_cluster's si/offset arrays, next array for rotational device). This currently expands to PMD_ORDER+1, which only works when PMD_ORDER is a compile time constant. However on architecture like PowerPC Book3S64, PMD_ORDER is a runtime variable which depends upon which MMU is selected (Radix / Hash), so in that case, PMD_ORDER cannot be used to size the static arrays. This patch provides an optional ARCH_MAX_PMD_ORDER (upper-bound) override for such architectures. The memory overhead on enabling this override is negligible. Even if we make SWAP_NR_ORDERS runtime alloc, default slab padding could cause some memory waste. Also we lose the per-cpu cacheline benefits (for percpu_swap_cluster) because it might cost an extra cacheline indirection overhead in swap_alloc_fast() for fetching si[order]/offset[order]. Note that a fully runtime SWAP_NR_ORDERS was considered in previous version but was dropped for this reason [1] [1]: https://lore.kernel.org/linuxppc-dev/pl1zdksc.ritesh.list@gmail.com/ Suggested-by: YoungJun Park Signed-off-by: Ritesh Harjani (IBM) --- arch/powerpc/include/asm/book3s/64/pgtable.h | 7 +++++++ include/linux/swap.h | 12 +++++++++++- 2 files changed, 18 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h b/arch/powerpc/include/asm/book3s/64/pgtable.h index e67e64ac6e8c..7f22d5d5fbdf 100644 --- a/arch/powerpc/include/asm/book3s/64/pgtable.h +++ b/arch/powerpc/include/asm/book3s/64/pgtable.h @@ -204,6 +204,13 @@ extern unsigned long __pmd_frag_size_shift; #define MAX_PTRS_PER_PGD (1 << (H_PGD_INDEX_SIZE > RADIX_PGD_INDEX_SIZE ? \ H_PGD_INDEX_SIZE : RADIX_PGD_INDEX_SIZE)) +/* + * Compile-time upper bound on PMD_ORDER across hash and radix MMUs. + * Used by THP SWAP code. Check include/linux/swap.h + */ +#define ARCH_MAX_PMD_ORDER ((H_PTE_INDEX_SIZE > RADIX_PTE_INDEX_SIZE) ? \ + H_PTE_INDEX_SIZE : RADIX_PTE_INDEX_SIZE) + /* PMD_SHIFT determines what a second-level page table entry can map */ #define PMD_SHIFT (PAGE_SHIFT + PTE_INDEX_SIZE) #define PMD_SIZE (1UL << PMD_SHIFT) diff --git a/include/linux/swap.h b/include/linux/swap.h index 8f0f68e245ba..317168aa2db5 100644 --- a/include/linux/swap.h +++ b/include/linux/swap.h @@ -229,11 +229,21 @@ enum { */ #define SWAP_ENTRY_INVALID 0 +/* + * ARCH_MAX_PMD_ORDER is an optional arch hook: a compile-time upper bound for + * PMD_ORDER across all possible MMU configurations of that arch. It is used to + * size SWAP_NR_ORDERS on architectures (e.g. powerpc book3s64) where PMD_ORDER + * is selected at boot rather than at compile time. + */ #ifdef CONFIG_THP_SWAP +#ifdef ARCH_MAX_PMD_ORDER +#define SWAP_NR_ORDERS (ARCH_MAX_PMD_ORDER + 1) +#else #define SWAP_NR_ORDERS (PMD_ORDER + 1) +#endif /* ARCH_MAX_PMD_ORDER */ #else #define SWAP_NR_ORDERS 1 -#endif +#endif /* CONFIG_THP_SWAP */ /* * We keep using same cluster for rotational device so IO will be sequential. -- 2.39.5