From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com [209.85.210.172]) (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 E1283238C15 for ; Sun, 25 Jan 2026 17:58:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769363883; cv=none; b=fKPp7yZO13MlqV3wofbOq2hGVqE2v25PssvWC0rN9iyxDmOTL4sEuWtOKGKOtoIPunuY/TpAqJpwbgVgvBOFoTq5iWfMER8kJlhOsu/zhYqSPZ6atab6/ja91+faemjZDY9it0iwLSUknivzwmPHv3Go8MRznwCSA7U2AjR9x4g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769363883; c=relaxed/simple; bh=huLDa8un5C6vRmWP03o1KHLIzmWyk50+wFZOq2REcWo=; h=From:Subject:Date:Message-Id:MIME-Version:Content-Type:To:Cc; b=hSCpX78L95HPRbAzGc/NGvsxoBp6jkLkxPlFrHnX5YUJ8KJGG/+tL14KuB5ES8/JA3yoXbWY1azlEoIXrjKQ/bdLNsQV/AbSz5VS0yw5ILTnXVTbduWArg1A3vK8EcDJrnrTRveGlpAONrD1s0bXEJhxsrrm9ShFiXYMfJ9FSDE= 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=hWWy2sTd; arc=none smtp.client-ip=209.85.210.172 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="hWWy2sTd" Received: by mail-pf1-f172.google.com with SMTP id d2e1a72fcca58-81f47610542so1906655b3a.0 for ; Sun, 25 Jan 2026 09:58:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769363881; x=1769968681; 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=HfwKtU2seymlppcOC0RwSpKtRsIq3Fv3RtXUlcD+w2c=; b=hWWy2sTdTwh4iXxq7Dkr0ANOcuWaM7xhrJKC/I5SriNuRTh4T2U/p+RgfEGF70gflW ZgSRXV6Ulj2tJlzJ/Q03s7ppFqjFGs6x2nTnuD04i7431CkaN2ZWC0Xt4ROfVv9/QjrE Ckankv0dOvmf/FVEVogKUwckbu0HFTv80x+d2ptFBgyouYZrMmTgHhDpn5LTSv4Mp8oh 9zLfBclaIp+tQAjufAkm1c/pX1Fep+aMV13MeeoRQYwvdRLlAmlYwtUlJQ4scBYELbOF YlQYaNr7szFPGSfzrWKwQTZwbwsP03ayWSlT1GMGIbSBmGTiejWYBBj/KR48pNv9KQEo ZiLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769363881; x=1769968681; 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=HfwKtU2seymlppcOC0RwSpKtRsIq3Fv3RtXUlcD+w2c=; b=Yrypr8b+DEUyAIco9A9xI5T3OGaCflVZ0rx4KiH5LubwmK3tUwknyFq7MEp19Dswmu CQxoA0VKkInEwnJa6CBVMsvt+pfsCxdLuucB/dIIVOKN5Yc7bEugV3j2MUUnovPfjTSX uYfHTHf+rwv0aUk6uKzdWeanmvTEvnkx9Boakhw+W0Um8q2gTrhSXIKGKwvGe+/JWwQm Mi/eSkUWMJrTXElXgQGAa4u+m2MuyVK+dm14BH7ewdU2R3Hrt1qZegThlUMEO+ierMNx zE7vzCbTmP36+LwJ9OzLu0ENcHHmk52pvC9/NRLVO7d7xrOy1kUJVTqS7VMEQf//tKs0 caeQ== X-Forwarded-Encrypted: i=1; AJvYcCW0cNrsKSlNLRY8+QOJLdMVA5pvdLH73A+DVUbS5bm7hIQnbW1akN6Gvv8D1lVZrvDP4mAYbxVRDbziWww=@vger.kernel.org X-Gm-Message-State: AOJu0YwgKaJisHVS7J1qldsSTMtfw+wtjAJqhyxkkYGv4QwEetR3A0NG 8eQQEtNsoQtUsRk38q4Q6twFdj3q+dBw7wMvxoNBnlAEe8fmucCJSQ8m X-Gm-Gg: AZuq6aKURaxZZjhyBhxwFAvaSQt7Mk3KruDcH/hIA1I0xbOD4GVqDa5H1naDc7KKhzI ZxRx5QtpAbW0QSZ3G5ve7wPBg/wrOZwuSs6l4BFjYsn2NsSX/yur7rmpLIEpsSTHb1beXocC2xl aJr8AkrS8wD2tluKrvnFQmHmryu8lcrCvZkrLIgDGBQfZ9wv0aCNFBZOj7LIpDTpISJ79wENHAD Mk0tlMkFXSBAmvJ5J6hFve5uwB2zhgr3VcB8tkMBpDRWdJy2haYc2cxF1wdRmO09+89WTe4CQGw 7vkyUSO/hZpit3JBniRBkvoZD9XEEZh5kAvgyg6VoODhwzvk33IGRJtI+n9bx2aADwY2nf8ShyC ligSRDGjg5K/XOfbzr+b9+Kn19HRYAU9OyKo8kEXDVE1PFX4AJanuFCe5sAHBqDT/ZOERH3wdl5 Iry0wUKYBWHn+ZbFdoQ8gj+ws+DxDytaFV6zIY9DtcuB9+zHTt X-Received: by 2002:a05:6a00:4fd0:b0:821:78ae:9dcd with SMTP id d2e1a72fcca58-8234120ac1amr1397845b3a.13.1769363881157; Sun, 25 Jan 2026 09:58:01 -0800 (PST) Received: from [127.0.0.1] ([101.32.222.185]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-8231876e718sm7405963b3a.62.2026.01.25.09.57.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 25 Jan 2026 09:58:00 -0800 (PST) From: Kairui Song Subject: [PATCH 00/12] mm, swap: swap table phase III: remove swap_map Date: Mon, 26 Jan 2026 01:57:23 +0800 Message-Id: <20260126-swap-table-p3-v1-0-a74155fab9b0@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/6tWKk4tykwtVrJSqFYqSi3LLM7MzwNyDHUUlJIzE vPSU3UzU4B8JSMDI1NDI0Mz3eLyxALdksSknFTdAmNdi5RUc+O01FTzJNM0JaCegqLUtMwKsHn RsbW1AK5unfxfAAAA 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 , linux-kernel@vger.kernel.org, Chris Li , Kairui Song X-Mailer: b4 0.14.3 X-Developer-Signature: v=1; a=ed25519-sha256; t=1769363877; l=3858; i=kasong@tencent.com; s=kasong-sign-tencent; h=from:subject:message-id; bh=huLDa8un5C6vRmWP03o1KHLIzmWyk50+wFZOq2REcWo=; b=FjANrUxyK+OFo1M//rfDxJgiThayWf5bCa79goHryuH1ul5Kq9y3WUf2lFQh2aBjQkM2h8xgr nSxfc4C2Ki7CTkVPMuVX72zklf+F6GLC8553NmVm4DUxCL2x3QSQnYB 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 --- 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 | 20 +- mm/swap_state.c | 72 ++-- mm/swap_table.h | 131 +++++- mm/swapfile.c | 1104 +++++++++++++++++++++----------------------------- mm/workingset.c | 49 ++- 7 files changed, 653 insertions(+), 753 deletions(-) --- base-commit: 10de4550639e9df9242e32e9affc90ed75a27c7d change-id: 20251216-swap-table-p3-8de73fee7b5f Best regards, -- Kairui Song