From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 3B9B420D4E9; Fri, 22 May 2026 01:52:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779414727; cv=none; b=LF9MiGk8IrJJQAtZqbaPov/EsHiEBkEntXxKYjPjx7RWHQzecVKgmmRiZINGpLJQaAE7YhQYDuh9P0R+h62WUue5u46zH1Wzy1eqP/I4dhDj26fttpwEbRJaJCZvCXRbH3uWPynR9EVnSIfaSY8qLhC3frZuIDI+Lwa2/VfkA/g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779414727; c=relaxed/simple; bh=3SyIRDl/2ZYw/U+KoPVPRqoM4BSNvIYZQ3+EC9K80iA=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=ii8QfelEN4t2OuBOnfRyEDDuBdMQTOXmzQ/2BasZd52HMyMTILMED/0jd5CWkUwR9N1bThMHUcypTs2sjIiGy5YT1DW1j7eX8x/IsL5fmRn0DRR72Cm+DJ5k3a5OenuEFRe8ag4mXqIzEiWQT4b/RxNkQmnEiSJKf7KknyW4DLI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=L2Lh02D+; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="L2Lh02D+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 12A231F000E9; Fri, 22 May 2026 01:52:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1779414725; bh=Dyfcsiq/DCFXpxq5yQbpU2tFM6IQFzSOs7Lzid8qTR0=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=L2Lh02D+6lZ2EjThkr03oBOiuaO2ST3bKnMDgaqAUoV/V2ap+v5QhU49hIhzv5YIE gTokUqnQb/0UGvN0asj/Aj/ZZ59YyBasIyRUxsL411orhSXQfXKpZzsnowk71dcsFi 3GWv1UkjvYatzyEj33JPVZk6lMsmZ6JMfSgH/lTU= Date: Thu, 21 May 2026 18:52:04 -0700 From: Andrew Morton To: kasong@tencent.com Cc: Kairui Song via B4 Relay , linux-mm@kvack.org, David Hildenbrand , Zi Yan , Baolin Wang , Barry Song , Hugh Dickins , Chris Li , Kemeng Shi , Nhat Pham , Baoquan He , Johannes Weiner , Youngjun Park , Chengming Zhou , Roman Gushchin , Shakeel Butt , Muchun Song , Usama Arif , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, Lorenzo Stoakes , Yosry Ahmed , Qi Zheng Subject: Re: [PATCH v5 12/12] mm, swap: merge zeromap into swap table Message-Id: <20260521185204.a109bfcd1e0e8f52135c5ed5@linux-foundation.org> In-Reply-To: <20260517-swap-table-p4-v5-12-88ae43e064c7@tencent.com> References: <20260517-swap-table-p4-v5-0-88ae43e064c7@tencent.com> <20260517-swap-table-p4-v5-12-88ae43e064c7@tencent.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: cgroups@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sun, 17 May 2026 23:39:51 +0800 Kairui Song via B4 Relay wrote: > From: Kairui Song > > By allocating one additional bit in the swap table entry's flags field > alongside the count, we can store the zeromap inline > > For 64 bit systems, zeromap will store in the swap table, avoiding zeromap > allocation. It reduces the allocated memory. That is the happy path. > > For certain 32-bit archs, there might not be enough bits in the swap > table to contain both PFN and flags. Therefore, conditionally let each > cluster have a zeromap field at build time, and use that instead. > If the swapfile cluster is not fully used, it will still save memory for > zeromap. The empty cluster does not allocate a zeromap. In the worst case, > all cluster are fully populated. We will use memory similar to the > previous zeromap implementation. > > A few macros were moved to different headers for build time struct > definition. > > ... > > @@ -469,13 +474,21 @@ static int swap_cluster_alloc_table(struct swap_cluster_info *ci, gfp_t gfp) > VM_WARN_ON_ONCE(ci->memcg_table); > ci->memcg_table = kzalloc_obj(*ci->memcg_table, gfp); > if (!ci->memcg_table) > - ret = -ENOMEM; > + goto err_free; > } > #endif > - if (ret) > - swap_cluster_free_table(ci); > > - return ret; > +#if !SWAP_TABLE_HAS_ZEROFLAG > + VM_WARN_ON_ONCE(ci->zero_bitmap); > + ci->zero_bitmap = bitmap_zalloc(SWAPFILE_CLUSTER, gfp); > + if (!ci->zero_bitmap) > + goto err_free; > +#endif > + return 0; > + > +err_free: > + swap_cluster_free_table(ci); > + return -ENOMEM; > } My m68k defconfig warned. I'll do the below, which looks good enough. Please check. Perhaps a custom guard() handler would clean things up here. From: Andrew Morton Subject: mm-swap-merge-zeromap-into-swap-table-fix-2 Date: Thu May 21 06:39:20 PM PDT 2026 mm/swapfile.c: In function 'swap_cluster_alloc_table': mm/swapfile.c:488:1: warning: label 'err_free' defined but not used [-Wunused-label] 488 | err_free: | ^~~~~~~~ Cc: Baolin Wang Cc: Baoquan He Cc: Barry Song Cc: Chengming Zhou Cc: Chris Li Cc: David Hildenbrand Cc: Hugh Dickins Cc: Johannes Weiner Cc: Kairui Song Cc: Kemeng Shi Cc: Lorenzo Stoakes Cc: Muchun Song Cc: Nhat Pham Cc: Roman Gushchin Cc: Shakeel Butt Cc: Youngjun Park Cc: Zi Yan Signed-off-by: Andrew Morton --- mm/swapfile.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) --- a/mm/swapfile.c~mm-swap-merge-zeromap-into-swap-table-fix-2 +++ a/mm/swapfile.c @@ -472,22 +472,22 @@ static int swap_cluster_alloc_table(stru if (!mem_cgroup_disabled()) { VM_WARN_ON_ONCE(ci->memcg_table); ci->memcg_table = kzalloc_obj(*ci->memcg_table, gfp); - if (!ci->memcg_table) - goto err_free; + if (!ci->memcg_table) { + swap_cluster_free_table(ci); + return -ENOMEM; + } } #endif #if !SWAP_TABLE_HAS_ZEROFLAG VM_WARN_ON_ONCE(ci->zero_bitmap); ci->zero_bitmap = bitmap_zalloc(SWAPFILE_CLUSTER, gfp); - if (!ci->zero_bitmap) - goto err_free; + if (!ci->zero_bitmap) { + swap_cluster_free_table(ci); + return -ENOMEM; + } #endif return 0; - -err_free: - swap_cluster_free_table(ci); - return -ENOMEM; } /* _