From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f43.google.com (mail-pj1-f43.google.com [209.85.216.43]) (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 10BE4287510 for ; Fri, 31 Jul 2026 00:32:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785457979; cv=none; b=b1qlpiDSKHHRqAbL83yGU3GGLVPtgmZUS8fsqhsv8gSrv8E7Fc+FLXhsBwg2TQbp0YKzhTZC8wf5g7737fP57SOPJIgrJAj5UuCJ0xTiFys9pZva3aN1SBJ9oGTau2qWZXtSWEa5NwNFrFdJjk/HP9bpBuyjszsXL1u9YXZkOUc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785457979; c=relaxed/simple; bh=5OE6LjCPVtiL+KDY4IYg+PiV0DUuj0qS5DY0YplDP48=; h=From:Subject:Date:Message-Id:MIME-Version:Content-Type:To:Cc; b=n1a+vRkwet2G22cV5RIC3KNpbtpzZFfTB2tt3q/7pyx/WHD7pZOy0OQCHUKiVsiA+8O/y32xzSKBfE6RpZSfjQoCHjwtMLnYdXaT0FrAEG8PFC5Q+xro2vv2rIAd8JtjV1s3hCKwMDHK4tZ0rP9GSTcRbgkC32N4JTDxHB4RiuM= 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=ZOZbiix5; arc=none smtp.client-ip=209.85.216.43 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="ZOZbiix5" Received: by mail-pj1-f43.google.com with SMTP id 98e67ed59e1d1-383b4a3755fso468732a91.3 for ; Thu, 30 Jul 2026 17:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785457974; x=1786062774; darn=vger.kernel.org; h=cc:to:content-transfer-encoding:content-type:mime-version :message-id:date:subject:from:from:to:cc:subject:date:message-id :reply-to:content-type; bh=+0vsC71zSDov/oBYPn9+nw22jst3hXsJQFoPYXKGz8o=; b=ZOZbiix5NcS2kUWZaT+jnSixcYOdCI6D4E88BCrcJzau8V0+GI7SlRY5Nz8nIEcwVb yYEMjbT6wZFl/jcLJcu6mn3IG4tf/1vG48E3h6fTRkMwT72aUid4ImHq4NZ1mX+n6HK9 nHkGF1l2vhbDPIQLn9IMJRXKioYggk6lNAvvvqyfdnrHRzedZWFEeFW+8AA7tJNWoN2x PbWNRQWL8kwwXixfWOqorWZo+qYL+A/Ya+pgBCnvSXS1seGTMEPwRtgSgQMwGGNvWf79 BnFEpNjO7NAGI+3Kb17jlJgEn6usI9ZGd4Eo84v31gInIGqjpi+u/pdT9zXaMz36u/kW vIXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785457974; x=1786062774; h=cc:to:content-transfer-encoding:content-type:mime-version :message-id:date:subject:from:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=+0vsC71zSDov/oBYPn9+nw22jst3hXsJQFoPYXKGz8o=; b=m8NTUBvoMqScmrNTbm5r1BoKy4H9AyLF8fr/9XN0x3Pgrx92MDGukWafaFOwTDZL7h VByeOGrL9FYPBZWP75F6jZJZKyEw6JGEsP6+Ms1ArekaI6/i5y+kDDke12KzDWg1pjiQ 7aSGtdlvsAxs3IbCEm4FKVPxyXurEsiYilx+yvbhaanQNsDbKCbRTNGo8iruW4nC+ai5 8wS22XGrhmGIWCd/dxos2NorsL3Jf3D+zsmvpTvjxM8LFFyg+x1yXOfkF8Emg0RrZaKY pMJD0/6cGCFqDxKz2JfdebzLB89sIKop1fDFw3yDdh0dx4lbyfR2M8bHawsRxLXmShGj jNjg== X-Gm-Message-State: AOJu0YzTGh+GLxy1YNhOn49BKMzokl52vemNbF1TqVFPgYaZSCu0BV7K Lp21fwQWFuaVkugYeUlY8hTlo62F11uVv6KJrrJ54AxmIpeKy7iH2sLy X-Gm-Gg: AR+sD12+3t79o0anTnkVjoUiEulONZ3cWIq8GHyBFfP/JBgVEPTOSvQXMYdo4/DyT7m aUBXOJebPNqCvrzTeBdPSnEAdxKhT2LziDQFSXixr3K5aQ5baXb3Bm9sLKPBoffj4Ut8UST/GCm BmqEJkrmfqZZLI7uRfAPBq265jcgm3oRH+e0wuNNoWC5e/O77enVg2yaYXSi9SfVMc5dv4btudt sn783xOuUuGQLu+9WqPQ8g6LW2Oafin5V/9yjVl8UtMYxAsSVkACDNtCG0OGO/wJVIZ1lYUniKj U4CUU7dyjuITTXWYJ/RCj2qqRtCR9b4GMN6e4TfwqDHz4Do2L/q+FKrZwmDCn7Heg5oN8/Gj7Bq 7WP6ePUgeu0vzB5oLcO2W9tFnuVhhUMcQ4fBd8HX3lmoy2RT6HlxHjv+SnNhVSQvdqGObY2oaME KoHFXMoXj8ql3x83GA7PZByYTMrjzsA4pG0ZscqbRLn2GNuKKw3Nai2G9UH1cir57zNuVN/Wq49 L3F5qGVTh38yu4ocB0qTkDodKSuSYw90Z/tlnQ= X-Received: by 2002:a17:90b:1c05:b0:387:e0db:3fb1 with SMTP id 98e67ed59e1d1-38f9c0bdc13mr3564460a91.42.1785457974396; Thu, 30 Jul 2026 17:32:54 -0700 (PDT) Received: from NV-J4GCB44.localdomain ([103.74.125.162]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-38f9b42d6c8sm1636301a91.3.2026.07.30.17.32.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Jul 2026 17:32:53 -0700 (PDT) From: Jianyue Wu Subject: [PATCH RFC v2 0/2] mm/zswap: shrink zswap_entry via a fixed pool index Date: Fri, 31 Jul 2026 08:32:46 +0800 Message-Id: <20260731-shrink_zswap_entry_v2-0-0-v2-0-e72083aa8734@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="utf-8" Content-Transfer-Encoding: 7bit X-B4-Tracking: v=1; b=H4sIAC7ta2oC/6tWKk4tykwtVrJSqFYqSi3LLM7MzwNyjHQUlJIzE vPSU3UzU4B8JSMDIzMDc2ND3eKMosy87Piq4vLEgvjUvJKiyvgyI10DIDQ3S0w2TkwzNEpNNlE C6i8oSk3LrACbHa0U5OasFFtbCwArxJ47cAAAAA== To: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, Johannes Weiner , Yosry Ahmed , Nhat Pham , Chengming Zhou , Andrew Morton , Chris Li , Jianyue Wu X-Mailer: b4 0.13.0 Every stored page has a struct zswap_entry, so its size is pure per-page overhead. On x86_64 it is currently 56 bytes, of which 8 bytes are a pointer to the owning zswap_pool. Only a handful of pools are ever live: a new pool is created only when the compressor is (re)set, and pools are reused across compressor switches. That makes a per-entry pool pointer more expensive than it needs to be, and the RCU list that currently tracks pools is more machinery than this needs once each pool already has a stable slot. This series replaces the list with a fixed array of ZSWAP_MAX_POOLS (16) slots, tracks the current pool with a separate RCU-protected pointer, then stores a u8 slot index in each entry instead of the pool pointer. The u8 fits in padding after the bool referenced field, so the entry shrinks from 56 to 48 bytes on x86_64 (~2MiB of metadata saved per 1GiB of data held in zswap). Runtime compressor switching is preserved; creating a 17th pool fails and warns. Patch 1 is the list -> array conversion. Patch 2 is the per-entry shrink. Looking for feedback on whether this is the right shape before sending a non-RFC version. Benchmark (x86_64, compressor=lzo, MADV_PAGEOUT store + fault-in load): - zswap_entry object_size: 56 -> 48 bytes - e2e store+load median latency: no measurable regression vs baseline at matched stored_delta The extra cost per store/free/decompress is one array-index load instead of a pointer dereference. With a single (or few) live pool(s) that does not show up against (de)compression. Changes from RFC v1: - Drop the allocating xarray; use a fixed array of 16 pools indexed by a u8, as suggested by Nhat and Yosry. - Drop the zswap_pools list and the per-pool list_head; the array carries stable slot numbers for entries, and a separate RCU pointer tracks the current pool. - Document the new pool-count cap; fail/warn when the array is full. - Clear the array slot in __zswap_pool_empty() before scheduling the release work (equivalent to the old list_del_rcu()), then synchronize_rcu() before free. - Use rcu_assign_pointer() / rcu_dereference*() for slot and current- pool publish/load. Entry lookup uses rcu_dereference_protected() because a live entry already pins its pool. - Add NULL checks on the resolved pool in free/decompress. Link: https://lore.kernel.org/all/20260726-shrink_zswap_entry_v1-0-0-v1-1-30957e4d0cb6@gmail.com/ Signed-off-by: Jianyue Wu --- Jianyue Wu (2): mm/zswap: replace the zswap_pools list with a fixed pools array mm/zswap: reference the pool by index to shrink struct zswap_entry mm/zswap.c | 119 ++++++++++++++++++++++++++++++++++++++++++++++--------------- 1 file changed, 91 insertions(+), 28 deletions(-) --- base-commit: 2ed26e8a624f41887d64e2e37a2f6ab36a118d1f change-id: 20260731-shrink_zswap_entry_v2-0-0-76ac3af12ec4 Best regards, -- Jianyue Wu