From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-171.mta1.migadu.com (out-171.mta1.migadu.com [95.215.58.171]) (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 B66D5405F7 for ; Tue, 7 Jul 2026 07:32:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783409552; cv=none; b=U2xdMR/DpACQjXxiFQX20msz4dGBrI7c4iuVg3RUmITkAvxBGFRaWovsmNz1FgDhHLcEuIuI0JF+tGzajMlESL0ocQGW+tBScOjz5MLH95wv4UVtYM4AU87QfWXbpq70WO1JCDrd2L07iKpVDDlQOa4YDTyMKtBnYEQUTzHW4vY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783409552; c=relaxed/simple; bh=Npi9WHkGJP/RzdfUHIliPHSeF+ekVWLFvAlVZwC/184=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-type; b=ie3e+K0ztQUvhtwjjCe8guCv1avTOYo4YIpUcT9er817cS5R6ynyeBbYgT1+cma8P0AvKXTscGb9ceFXvZlSsDej2P98kvqCgeX0zgwxgkma2z7CkUoWkv7iCsvVf96frRCBSskVC6RbIwYCW4+QhoczGc60PqeN4WSjm9KNTPE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=U/ua+vsv; arc=none smtp.client-ip=95.215.58.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="U/ua+vsv" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1783409547; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=WJQsLVBduOuIi79XguxT1NsduIFnIZt/nxYyMr+Hge4=; b=U/ua+vsvKpX1CMOfyJAksgxiQ3qp82R7rn6yXQ52MclaJYxp8UI0k0JG7yG473U725Bq4N gUuzr7/v8kF0+BxYiwibZr1v/0Wp0zR987fed5YxpbBxhtcTVF/b1G/rVZcZpyNb9KHP9r +dbSbbD15hJCJtWqEu0c30IsOO5Zpy8= From: Baoquan He To: linux-mm@kvack.org Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, yosry@kernel.org, nphamcs@gmail.com, chengming.zhou@linux.dev, chrisl@kernel.org, kasong@tencent.com, shikemeng@huaweicloud.com, baohua@kernel.org, youngjun.park@lge.com, linux-kernel@vger.kernel.org, Baoquan He Subject: [RFC PATCH 0/7] mm: store zswap entries in swap table (Pointer entry) Date: Tue, 7 Jul 2026 15:31:57 +0800 Message-ID: <20260707073215.72183-1-baoquan.he@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-type: text/plain Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT Currently zswap uses a per-swap-device xarray to map swap offsets to zswap_entry pointers. This introduces an additional tree walk on every zswap entry access. This series replaces the xarray with a "Pointer" entry type stored directly in the swap cluster table. The new swp_tb_t variant embeds a zswap_entry pointer plus a entry count, eliminating the xarray and its lookup overhead entirely. Design overview --------------- A swap table slot can now be one of five types: NULL: |---------------- 0 ---------------| Shadow: |SWAP_COUNT|Z|---- SHADOW_VAL ---|1| PFN: |SWAP_COUNT|Z|------ PFN -------|10| Pointer: |----------- Pointer ----------|100| Bad: |------------- 1 -------------|1000| When zswap compresses a page, it saves the original swap table entry (PFN or Shadow) in zswap_entry->swp_tb_val, then writes the Pointer entry into the swap table. The swap count and flags remain accessible via helper functions that read them from swp_tb_val. The zswap_entry is threaded through the swapin call chain via a new void **zentry parameter, so zswap_load() receives it directly instead of doing an xarray lookup. Performance ----------- [~]# free -h total used free shared buff/cache available Mem: 3.8Gi 155Mi 3.4Gi 656Ki 315Mi 3.7Gi Swap: 4.0Gi 54Mi 3.9Gi Scalability benchmark: 'usemem -O -y -x -n 1 5G', 10 runs under cgroup MemoryMax=2G MemorySwapMax=3G. zswap enabled with zstd compressor. Kernel A: cfb8731f5396 (xarray-based lookup, baseline) Kernel B: (Pointer entry) 5G test — the gap widens significantly as swap pressure grows: Metric xarray(A) Pointer(B) -------------------------------------------------- Avg throughput 709,556 KB/s 792,681 KB/s (+11.7%) Avg free time 167,994 µs 132,896 µs (-20.9%) Free time trend across 10 rounds at 5G: Pointer: 126→124→126→126→124→129→138→145→142→148 (gradual, +17%) xarray: 136→139→136→160→162→161→159→230→219→178 (collapse, +31%) xarray degrades sharply in the later rounds (last 3 avg free time 209 ms vs Pointer's 145 ms, 1.44× worse) as the radix tree insertion/deletion cost grows non-linearly under sustained swap churn. Pointer entry avoids this entirely by looking up entries directly in the swap cluster table, which is already hot in cache. Baoquan He (7): mm/swap_table: add Pointer type support for zswap entry storage mm/zswap: add swp_tb_val to zswap_entry and Pointer accessor helpers mm/swap_state: do zswap conversion in __swap_cache_do_del_folio mm/zswap, mm/swap_state: handle Pointer entries in add_folio path mm/swapfile: handle Pointer entries in count/dup/put paths mm/zswap, mm/swap_state: migrate zswap to use swap_table for entry indexing mm/zswap, mm/swap_state: replace xarray indexing with swap table lookups include/linux/zswap.h | 4 +- mm/page_io.c | 4 +- mm/swap.h | 52 +++++- mm/swap_state.c | 117 +++++++++++--- mm/swap_table.h | 35 ++++- mm/swapfile.c | 107 ++++++++++--- mm/zswap.c | 358 +++++++++++++++++++++++++++++------------- 7 files changed, 508 insertions(+), 169 deletions(-) -- 2.54.0