From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f182.google.com (mail-pg1-f182.google.com [209.85.215.182]) (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 5E2C0346E6E for ; Wed, 28 Jan 2026 09:30:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769592633; cv=none; b=Hx8Qpb5sHhXlIIsvp3lX45EKlxDtW063ETXYcaXzs1YY9E5HeqNezKlt76sJQUZpW1DQvvVE9qaTg/c5XTTp5qbJriLR9/kox3XfunqPLsXl2w1BIaFP6IxWz8Q6QXX7o/lBRMXlIiRNd6TZZChh+BnPWaqpNl2T5kOfuzGL+3c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769592633; c=relaxed/simple; bh=twxbP0g4CrwvblUjXGxqvuvnnM3ZU03eSXMb1SiZqyw=; h=From:Subject:Date:Message-Id:MIME-Version:Content-Type:To:Cc; b=B23WyUV/MlmyViWWmVX0B+qoyj7QwLijmZy2i5adSqKEhtIxOBeLWqc1W54z9txp03vN3QASiIZkWbpwL6Gt2qZ2Z/9iY/8DcaJP8Qpy6QGmNN/3j+jtQhF80NMyetNC1NhSn4aEVMSIs4IYbB6gZvLM8GgZS8KIyjF668yjOHI= 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=FOFM/e6K; arc=none smtp.client-ip=209.85.215.182 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="FOFM/e6K" Received: by mail-pg1-f182.google.com with SMTP id 41be03b00d2f7-c227206e6dcso4452775a12.2 for ; Wed, 28 Jan 2026 01:30:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769592632; x=1770197432; darn=vger.kernel.org; h=cc:to:content-transfer-encoding:mime-version:message-id:date :subject:from:from:to:cc:subject:date:message-id:reply-to; bh=CWU5+GI80rzKUvfGPShbg6eie5kBzuS4F6usClrZBLY=; b=FOFM/e6KSowo5jeA0IGAS6YldGfNjvuH6gmg9dUhPhGCxo8hA1yfl25IptY05jR6MG IHQ1bhUIIdBsuJfmBM+m8UYAjvl+YyZt/9beB4w8KeiHXMDrWtRnD2wlwMm1KYr1Sn48 u3dTgOeLmj1EIqQwD+rGzJHDzU5gjfI1e2WHnFGCVPH3OJ+iLRmKFuYE6OOPz8debfba IPu8plGyC+S27H0u/cqUBdXsHZ5GHJHeMGb/bJw9aWPX9FyNb7BvsCNONqWEmgKaHDaD yM/VWRFWVRxxEzHYLcQH9M/qN38Rm5dYXMWRos2RNmvhwjbEMUgD5K8voxyokyJtpxjn AVGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769592632; x=1770197432; h=cc:to:content-transfer-encoding:mime-version:message-id:date :subject:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=CWU5+GI80rzKUvfGPShbg6eie5kBzuS4F6usClrZBLY=; b=FxrIIoIKXkQThNG4OpxYMf7z3iLkqJJY2EOpCUiHGr8pR3DFBstmuto6WKHgodMa8o C1TGwNmJNQ8EKnPcvXgawHLXS5ewyYgCPbyV0PEuDt2QQeJ0QXZD/0oSNjbGgFxhMvOC Z5fsWHg2dzSWqg78V1q5zkUdwsI22KLW8vfa+K/7i5iOnnZgxOTupQuwUNb0AV8xLPm0 WkG1xPhaZY+zej+2+LBcbkoakfRhvVflvgkREBVhaM2qhIFbZT9U1ORuttNPi5sNSgnZ dWGFA+9FT9AhL02QIGWDiLUDaNqYbH/P3M5jPIumkC0tUGiY2+CgMrUs5LRyu4Vd+Zd3 eY0A== X-Forwarded-Encrypted: i=1; AJvYcCWa8KOmcgsPS/wg/WhSDVFDPfYh9Ez+5TgbN95mTQQa66DZxkVeDf15EB/QtAVqPr+N/YqpfznQEu9pTKQ=@vger.kernel.org X-Gm-Message-State: AOJu0YxZnnmq44cqjYtW4H4QUXoDokuSfwYpiplQwfKQd1/okRdltrOK A9J72SESMYZNgLNiA0LDmLIAg3zI0aqu+IWv4BjM79Z06oMxuj8xfeuwtgCstHyI3ug= X-Gm-Gg: AZuq6aISiV3ZJG+rSHJ207Fkdlb8pdD0ObZLxlSEDOg0kYRVzoiSuFpUa0UqYNPpuD4 ntrz+dREEej/LZRly4bl/tf9OfonCN/n1fiERxCsatSpqivUQz1jtR4p1qZBs6db+/wHykaUo3V y/7BuLyPeG2dEBOZGUsnJgEJYbKSXkf5EHk3fGNS9pY+NeW0axkjiLXcWO56SsoT0h4+VdZfx94 wh85w0KvihObXl3NdMxy9HpG+TcksxSIdBZU7OBM5sg0wdiTQVmEMjD1QYleDEWt0Z0XJHD/jwj ZJ0OA1PPmA4NLBGyhn6MqWbnAtQWQyNCda8nzo5KyqdR1eYBYXLhu5zMeFa7ZOnbS6MSM6T2v0x ohpTsQhLWTt37qBS1Kle9/gbJYfm14ht350cnfxJ1vrgDeqIk7uUGK6qtsZyRxtDmAj7lUADO93 vpdpDkCqPdlkAAmaZL5N3zldw3ptX3lcEw+J9o3S+HBYutnR/ghS2ChcV6MA== X-Received: by 2002:a17:90b:2789:b0:34c:cb3c:f536 with SMTP id 98e67ed59e1d1-353fedbb396mr4978524a91.36.1769592631687; Wed, 28 Jan 2026 01:30:31 -0800 (PST) Received: from [127.0.0.1] ([43.132.141.21]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3540f3eca6dsm1872235a91.15.2026.01.28.01.30.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Jan 2026 01:30:31 -0800 (PST) From: Kairui Song Subject: [PATCH v2 00/12] mm, swap: swap table phase III: remove swap_map Date: Wed, 28 Jan 2026 17:28:24 +0800 Message-Id: <20260128-swap-table-p3-v2-0-fe0b67ef0215@tencent.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="utf-8" Content-Transfer-Encoding: 7bit X-B4-Tracking: v=1; b=H4sIAAAAAAAC/13MQQ7CIBCF4as0s3YMUCnqynuYLqAdLIlCA6RqG u4u7dLl/5L3rZAoOkpwbVaItLjkgq8hDg0Mk/YPQjfWBsGE5IJ3mN56xqzNk3Bu8TySai2RMtJ C/cyRrPvs3r2vPbmUQ/zu/MK3dZM6xsW/tHBkqNWJS2m1uRh2y+QH8vk4hBf0pZQfvk7J8qwAA AA= X-Change-ID: 20251216-swap-table-p3-8de73fee7b5f To: linux-mm@kvack.org Cc: Andrew Morton , Kemeng Shi , Nhat Pham , Baoquan He , Barry Song , Johannes Weiner , David Hildenbrand , Lorenzo Stoakes , Youngjun Park , linux-kernel@vger.kernel.org, Chris Li , Kairui Song X-Mailer: b4 0.14.3 X-Developer-Signature: v=1; a=ed25519-sha256; t=1769592628; l=4647; i=kasong@tencent.com; s=kasong-sign-tencent; h=from:subject:message-id; bh=twxbP0g4CrwvblUjXGxqvuvnnM3ZU03eSXMb1SiZqyw=; b=lCPeHPz6DUFJ2ww2Ne99AdSNMb3RP8bQZPv7KTiwIa8i/Xse0MopcYlXi+ciRLcD5+ibVAzG3 7v2N5Ee6wBuCWZ3/+3qOnRC0NBtow+djUmz6+9KwoozbKVLBnmr8XW7 X-Developer-Key: i=kasong@tencent.com; a=ed25519; pk=kCdoBuwrYph+KrkJnrr7Sm1pwwhGDdZKcKrqiK8Y1mI= This series is based on phase II which is still in mm-unstable. This series removes the static swap_map and uses the swap table for the swap count directly. This saves about ~30% memory usage for the static swap metadata. For example, this saves 256MB of memory when mounting a 1TB swap device. Performance is slightly better too, since the double update of the swap table and swap_map is now gone. Test results: Mounting a swap device: ======================= Mount a 1TB brd device as SWAP, just to verify the memory save: `free -m` before: total used free shared buff/cache available Mem: 1465 1051 417 1 61 413 Swap: 1054435 0 1054435 `free -m` after: total used free shared buff/cache available Mem: 1465 795 672 1 62 670 Swap: 1054435 0 1054435 Idle memory usage is reduced by ~256MB just as expected. And following this design we should be able to save another ~512MB in a next phase. Build kernel test: ================== Test using ZSWAP with NVME SWAP, make -j48, defconfig, in a x86_64 VM with 5G RAM, under global pressure, avg of 32 test run: Before After: System time: 1038.97s 1013.75s (-2.4%) Test using ZRAM as SWAP, make -j12, tinyconfig, in a ARM64 VM with 1.5G RAM, under global pressure, avg of 32 test run: Before After: System time: 67.75s 66.65s (-1.6%) The result is slightly better. Redis / Valkey benchmark: ========================= Test using ZRAM as SWAP, in a ARM64 VM with 1.5G RAM, under global pressure, avg of 64 test run: Server: valkey-server --maxmemory 2560M Client: redis-benchmark -r 3000000 -n 3000000 -d 1024 -c 12 -P 32 -t get no persistence with BGSAVE Before: 472705.71 RPS 369451.68 RPS After: 481197.93 RPS (+1.8%) 374922.32 RPS (+1.5%) In conclusion, performance is better in all cases, and memory usage is much lower. The swap cgroup array will also be merged into the swap table in a later phase, saving the other ~60% part of the static swap metadata and making all the swap metadata dynamic. The improved API for swap operations also reduces the lock contention and makes more batching operations possible. Suggested-by: Chris Li Signed-off-by: Kairui Song --- Changes in v2: - Fix build error for ARC with 40 bits of PAE address, adjust macros to shrink SWP_TB_COUNT_BITS if needed, and trigger build error if that field is too small. There should be no code change for 64 bit builds. - Fix build warning of unused variables. - SWP_TB_COUNT_MAX should be ((1 << SWP_TB_COUNT_BITS) - 1), not ((1 << SWP_TB_COUNT_BITS) - 2). No behavior change, just don't waste usable bits and reduce the chance of a slower extended table path. - Add a missing NULL check in swap_extend_table_try_free. - Fix a typecast error in the swapoff path to silence some static analyzer. - Stress tested setups with SWP_TB_COUNT_BITS == 2, looks fine. - Link to v1: https://lore.kernel.org/r/20260126-swap-table-p3-v1-0-a74155fab9b0@tencent.com --- Kairui Song (12): mm, swap: protect si->swap_file properly and use as a mount indicator mm, swap: clean up swapon process and locking mm, swap: remove redundant arguments and locking for enabling a device mm, swap: consolidate bad slots setup and make it more robust mm/workingset: leave highest bits empty for anon shadow mm, swap: implement helpers for reserving data in the swap table mm, swap: mark bad slots in swap table directly mm, swap: simplify swap table sanity range check mm, swap: use the swap table to track the swap count mm, swap: no need to truncate the scan border mm, swap: simplify checking if a folio is swapped mm, swap: no need to clear the shadow explicitly include/linux/swap.h | 28 +- mm/memory.c | 2 +- mm/swap.h | 22 +- mm/swap_state.c | 72 ++-- mm/swap_table.h | 138 ++++++- mm/swapfile.c | 1111 +++++++++++++++++++++----------------------------- mm/workingset.c | 49 ++- 7 files changed, 663 insertions(+), 759 deletions(-) --- base-commit: b2394bad912787054d79bf22303dd03eb59aa416 change-id: 20251216-swap-table-p3-8de73fee7b5f Best regards, -- Kairui Song