From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com [209.85.216.41]) (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 E0AB8165F16 for ; Wed, 17 Jun 2026 04:23:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781670223; cv=none; b=l8JG00C3AVCN2covxCb4SN1qabRhhDuZOF7jYWbEuQlcmM2+Lh54Z/fRS4tqMCyzZqGtPNXpL/my1RylDwkaJ0dLBNRjs2L3QLrscAQwDuckN+d0xLG8ooHlpPphWF4JXkbcsGrT3cJGriiDPylBxY7S5CQN/kGaDAH43G5c9qM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781670223; c=relaxed/simple; bh=7Gd7ThWD7ehAqS65dELA6Nm/uC6dwn5OAXW+j8eeb64=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=EzzBOE+AihjfDelFYb31TGd0A+mKbHfhbjpd0b8jvPYQIeCmfXK0TzxvovYFWcjBLsDcOLu7sEu8N00NHnr11/kYmvZYPVKprmeP9xY13Ibxle/uFMKz7iDxcks0lS+jeRFUnpCT38f+HH8S5kOKreZftrcVb5vTvzj4stkuRj8= 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=Co0Yw5AG; arc=none smtp.client-ip=209.85.216.41 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="Co0Yw5AG" Received: by mail-pj1-f41.google.com with SMTP id 98e67ed59e1d1-37c64d34032so247963a91.0 for ; Tue, 16 Jun 2026 21:23:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781670221; x=1782275021; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=pDWfBHCIgx7ksbfZa1ubRGAaRoFfFBx7ZNK9YSokzdM=; b=Co0Yw5AGT5gOPZsYa5ciEAIQTKFEvBaM0MgrTRUY8f1TCxMDNj5H7SX4f9XZ5ssClU +8odikMa3BE28xn38pXov28ana8BJ1w2q+K5u2OSDaXcurCgSb8ltdJsJ8scMPc78fB7 2r9TPzy39VJ+DGGP25W9+b7XfJqqaLQeuZpkW8D+O9pcU3XZFVbODylu32vO22ChoT/P +oUWpxdgdC8L1z4ue64t9iu3F9mJKfGz1VPnu1/CxGP2jec8aKU/MScv1vmAf9iYUNd+ tf2x7kVuErtxEGhxodW0M4BnU5qS8FD7Lhm6IxWqTuY3h7TEEXz+HVTiefPBS6ushbO4 fiyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781670221; x=1782275021; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pDWfBHCIgx7ksbfZa1ubRGAaRoFfFBx7ZNK9YSokzdM=; b=tU4nCcam/t5JUK8TpXScjD/KY4nTK1kobb4+/kYMCYyzv9GF/nclEOPaGhtSVCtNJ6 jNxN0Y7n81HCezY2kO9BUO6Q0MbajGwOaPjD18QiEHzNwhajOkj/KW6X/z+TAp2P5kPj 5FP52y+bv490LId1lk3Nb8lEjzzxluCFJNBE4yaReMQGAYS89aUXIB74FF9zCNufhgpD dh8mZ/Y4d5iEuCd1BQCWEULhBup5C9Q3d1j8rKB5Pet3aNBCeMYYUn/sFrZviSKgbSB4 KjHFBVYN3MUyuAqhdXf1X+Y/UbK8PvPga8fxy58Mw8Lc4ScBwTsu3bmNHbVWgURbCb07 GZMQ== X-Forwarded-Encrypted: i=1; AFNElJ8uX+QU5hlKARnReGcxblVw6SSLMcj6eI+go9aYiYQ0sJ0C+JgdQXWHkGPmXew/C4+SVOxf2m/DJTk/J9w=@vger.kernel.org X-Gm-Message-State: AOJu0YyTw91+wTkpsC6v17n4OgGKRIx15fBC8db/lcKQKscOhw+hxHCL 0OLiLkPLDMUcRo6WzANtUbHEoo5AyJHSEOyc0Gz7TNBk12OsIeUmOj2Z X-Gm-Gg: AfdE7cnx4NUUIasfvqjyx7ybrnXb5e8SX4IYaD+GkdMZz3ZaprZVB6SVJ7F06OT+3uH rz8Oe0ZAUihNAYVsWy6qxu8l0ABYkpkTaZnFeowZPlRSURH82iZqxZYbeRsW/KOeWBPr9GCNcLZ 5TtXWQoU5CBTnzqMO9pkMVM0B6UQ5FhhSRcDOmdBCrhK9ybRMES9yzmSidlQOq4nDTePPs6icGu BxceBf4dUp1eobVn81wshEGp8QTYHc1/Qhc8efigyVLmuIif8ih2XhQ7xdFWvzGjk8Au7f1riFJ nUIqHoApS/r+hEpg7SQd1xW9yAms/ta2GvuWAcRGBspPd3m7JJWwieduo7xnqF8wwihUI6O6/mC fkB8/KPVlw+uXVR+cfbch+B0wETMrx8kkvGhHtCNMvIw/mZd22veYOq2TKY/wbpg/xuycN57bs1 r2fcJ0Tdjturkn2/AbwcA4rbSJ9+49FsKXsA8PBQViuOMhjJWZJPkwVq1rgxL1j3O6BrGo X-Received: by 2002:a17:90b:3ecd:b0:36a:8254:8eb1 with SMTP id 98e67ed59e1d1-37ca6a6c890mr1013456a91.6.1781670221256; Tue, 16 Jun 2026 21:23:41 -0700 (PDT) Received: from KASONG-MC4 ([43.132.141.24]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-37ca1dab259sm689079a91.2.2026.06.16.21.23.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Jun 2026 21:23:40 -0700 (PDT) Date: Wed, 17 Jun 2026 12:23:34 +0800 From: Kairui Song To: "Ritesh Harjani (IBM)" Cc: linux-mm@kvack.org, 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 Subject: Re: [PATCH v3 1/3] mm, swap: make SWAPFILE_CLUSTER runtime Message-ID: References: <1e8d7e4d0bb1377277ae8b6561d89fa0e048e7de.1781287297.git.ritesh.list@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1e8d7e4d0bb1377277ae8b6561d89fa0e048e7de.1781287297.git.ritesh.list@gmail.com> On Fri, Jun 12, 2026 at 11:39:15PM +0800, Ritesh Harjani (IBM) wrote: > On PowerPC Book3S64, MMU is selected at runtime, so macros like > PMD_SHIFT are effectively runtime variables in the Book3S64 code. THP > swap code uses these macros to size some of its array data structures > based on PMD_ORDER e.g. SWAPFILE_CLUSTER macro is used for this very > purpose. > Hence this patch initializes SWAPFILE_CLUSTER at runtime and also > modifies swap_table and swap_memcg_table which were earlier using this > macro for defining the number of table entries. > > Signed-off-by: Ritesh Harjani (IBM) > --- > mm/swap.h | 5 +++-- > mm/swap_table.h | 6 ++---- > mm/swapfile.c | 27 ++++++++++++++++++++++----- > 3 files changed, 27 insertions(+), 11 deletions(-) Hi Ritesh, Thanks for the patch. > > diff --git a/mm/swap.h b/mm/swap.h > index 77d2d14eda42..956879a69ddd 100644 > --- a/mm/swap.h > +++ b/mm/swap.h > @@ -26,11 +26,12 @@ extern int page_cluster; > #define SWAP_TABLE_HAS_ZEROFLAG ((BITS_PER_LONG - SWAP_CACHE_PFN_MARK_BITS - \ > SWAP_CACHE_PFN_BITS) > SWAP_COUNT_MIN_BITS) > > +extern unsigned int swap_slots_in_cluster __read_mostly; Maybe __ro_after_init is better for this kind of use case? > +#define SWAPFILE_CLUSTER swap_slots_in_cluster > + > #ifdef CONFIG_THP_SWAP > -#define SWAPFILE_CLUSTER HPAGE_PMD_NR So on Book3S64, HPAGE_PMD_NR is also a variable right? Then we don't really need to change the SWAPFILE_CLUSTER defination here? We just need to adjust the users of this macro so the build will pass? Or maybe use another macro instead of HPAGE_PMD_NR here, whichever is more arch friendly. That way if that is a build time constant, all users are folded to just one mask/shift which is super efficient especially for inline helpers, and there are a lot of them. Only special archs live with the dynamic load overhead.