From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9B90DC0218A for ; Tue, 28 Jan 2025 15:27:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 12FEA280237; Tue, 28 Jan 2025 10:27:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0B9AC280236; Tue, 28 Jan 2025 10:27:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E7528280237; Tue, 28 Jan 2025 10:27:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id C3860280236 for ; Tue, 28 Jan 2025 10:27:47 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 665A148FEF for ; Tue, 28 Jan 2025 15:27:47 +0000 (UTC) X-FDA: 83057240574.09.8314446 Received: from out-182.mta0.migadu.com (out-182.mta0.migadu.com [91.218.175.182]) by imf01.hostedemail.com (Postfix) with ESMTP id 7856D4000B for ; Tue, 28 Jan 2025 15:27:45 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=r9YjKK+C; spf=pass (imf01.hostedemail.com: domain of yosry.ahmed@linux.dev designates 91.218.175.182 as permitted sender) smtp.mailfrom=yosry.ahmed@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738078065; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=cFCNtAn5R1/J8OkrjH7fIuh6DZ056MfqldMmOKH0a0A=; b=ay49xnjThkD60hFlX8gjaf8MwH+gAxc1eZStWN4UuYMBPsmxE4cLKMd4diUhCiEGUvIPjT 73nbF02UdfPib8iu6gOWFKMh1XvZzEGMAsurEbVgGz5gz185vyZDBwuMa0gAzlx3QbmuBh HU66hwrOS4UyXQyGkkpuF+XMs/kb60E= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=r9YjKK+C; spf=pass (imf01.hostedemail.com: domain of yosry.ahmed@linux.dev designates 91.218.175.182 as permitted sender) smtp.mailfrom=yosry.ahmed@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738078065; a=rsa-sha256; cv=none; b=j2V2HustFECQMNgS1v45dZGttjoE75lSQ0WUx62TKOqUAG339gIL4M4/kd3dY2jnqu2x2S ZO8oIi5mEN+UnCKA1Q9ddOMsSp4ZCSg1iPRNcLJTq4IQ7YUsmMffWnU+K9iLwH21ZHbb/X T38gR8gMjNRUJ4kJJNvk8PSf8R8bt2E= MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1738078058; 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: in-reply-to:in-reply-to:references:references; bh=cFCNtAn5R1/J8OkrjH7fIuh6DZ056MfqldMmOKH0a0A=; b=r9YjKK+CYNqhDq3GjbmHTYN231J4L4YZ1VwSAFkBHmJpNjoAjHhctZN10oH6ZDF1iE7Ogh HSIwBkp1KU9plof6T8OyUsybaxSn6xszzKr5jqCLGqNhIsXuNE0jpPgLXmnHnhS9owCHUT OjcUX6/Mcar02C9KT6MD2yKjJUcKcGQ= Date: Tue, 28 Jan 2025 15:27:36 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: "Yosry Ahmed" Message-ID: <0e3b587f8905c276952963122a675597d1774dbc@linux.dev> TLS-Required: No Subject: Re: [PATCH 1/2] mm: zbud: deprecate CONFIG_ZBUD To: "Johannes Weiner" Cc: "Andrew Morton" , "Vitaly Wool" , "Miaohe Lin" , "Nhat Pham" , "Chengming Zhou" , "Huacai Chen" , "WANG Xuerui" , linux-mm@kvack.org, linux-kernel@vger.kernel.org, loongarch@lists.linux.dev In-Reply-To: <20250128101442.GB691108@cmpxchg.org> References: <20250128101442.GB691108@cmpxchg.org> X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 7856D4000B X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 4hc8usr519idimkeyzzady8nj7kwjd8h X-HE-Tag: 1738078065-68165 X-HE-Meta: U2FsdGVkX1/5x0UV1BGXg/mLYZ5U5aa4XRVp2CMO1XhsdtF8GgXLk64APFnaNmrdFfqc6ab+YWZhFUMRQyTlZPQhYX/jTnp36TLcOY3kfHFyQyqGjMQcuFGJex6GXUEBTVqgkX4aqJX8ZMc5M5fHDr31ILszrBdj5d4BuiyqcscwJvPYvIyVr+l7S2Rpxj/aooASwCITr8rtZciXzOoa9Cpt0hfvcgY4vrFxnDvLGRVYjc19N6yPfbqBVNrI3ZqUihV6aZYmjeCpVWcYelo5ZFuU19feuE47WkbosJWvqaQk7lMc99zuCYx+M324Mkxxg+wEINi4rmwiRwhNc2VjNVJvcnwLSSdRYezO+9HunerxKagu1sLUS2XNOWDvUJGylT+oOMpJeZ7laCtDXWoE6gaCrPdpTFnfe6eVqbGP02dlg/XBDzj9UwgyD6tqSuZlmCSxZLBILDQHnA3YzRF1otS4pdJtFTKJt0iQHxwai/QRvhkt4uB3ZC19dkkI0qHk9nDoOwv6xR3k3WxY5xZd8uGcOL9lknQ08vEEzo+l6LMiBSC8OSI+g1tMN6uFmcO4zBuFaZk0iCAr5wLkhKaXyBau0azIl0/sfCyGgfwl5lUcH5e5JpWtqXULQi7GiLfV7H0PWqj06ccmKwFUGhC+ut4anv4H+H2Mtew8+rMUUN4IJN96Ki/wq2S/PRdcOVBtgbE5O97bp6oQHNfNmop7Rj4IfCTPr26UgUysBEMkLTm3hew/w8IrNJw/bnrrbkzNLIB7utD1k/hnyLBTvhxAuzdv7h5w12MXSQ2V6p8EtckvKnbKt0GTz5fE//IF4nQhxE04AboubBUbcuaillziP82GOJSr2813z5QMZyayq4wsnT86P3fUzJ54Hn8kXWoM9YTKn9CiM0ByVwDs7d6Sh1OKPteVj6F/6DAmpaGgm0UYTarC+apqxSTfw80rqlWC0dNzzngKQEtmulkvuh9 4ULpNqQp Yw4Xllgc/OuFTM+34Y48YzqFniQjcP8pQ2BoktRlgtF/3nWbx9hG1IMBYfCAq6+UkBouwnY8C4HR6MUMXV0qk5xIve8hvvs4XhOW/QFQ8DyYK+6vF7LkT3km/4lI7WmHbaQhtcehYsUEvMiMqD5pWo1+ks3EgmDrvV2GrUhStwc/DJx2monhJOfcuShR1cp3TH1qS2KvonctmQP/bfISKBj+sZeI7mnoiRceU/h7ia0Mrz1x3c1ACxDFn25YE0ehsKbom/rVn8JTOpYCBMc18KGocNLLLbP2KvucUcwNXtCIpbzTE1ZAUmSMkVjI2DlXRz4iGAqj8IhehT1Ri7Mmq/m7W57HAPZVvCTkJpo5/BN1MPdQ= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: January 28, 2025 at 2:14 AM, "Johannes Weiner" wrote= : >=20 >=20On Mon, Jan 27, 2025 at 11:58:21PM +0000, Yosry Ahmed wrote: >=20 >=20>=20 >=20> The zbud compressed pages allocator is rarely used, most users use > >=20 >=20> zsmalloc. zbud consumes much more memory (only stores 1 or 2 compr= essed > >=20 >=20> pages per physical page). The only advantage of zbud is a marginal > >=20 >=20> performance improvement that by no means justify the memory overhe= ad. > >=20 >=20>=20=20 >=20>=20 >=20> Historically, zsmalloc had significantly worse latency than zbud a= nd > >=20 >=20> z3fold but offered better memory savings. This is no longer the ca= se as > >=20 >=20> shown by a simple recent analysis [1]. In a kernel build test on t= mpfs > >=20 >=20> in a limited cgroup, zbud 2-3% less time than zsmalloc, but at the= cost > >=20 >=20> of using ~32% more memory (1.5G vs 1.13G). The tradeoff does not m= ake > >=20 >=20> sense for zbud in any practical scenario. > >=20 >=20>=20=20 >=20>=20 >=20> The only alleged advantage of zbud is not having the dependency on > >=20 >=20> CONFIG_MMU, but CONFIG_SWAP already depends on CONFIG_MMU anyway, = and > >=20 >=20> zbud is only used by zswap. > >=20 >=20>=20=20 >=20>=20 >=20> Following in the footsteps of [2], which deprecated z3fold, deprec= ated > >=20 >=20> zbud as planned and remove it in a few cycles if no objections are > >=20 >=20> raised from active users. > >=20 >=20>=20=20 >=20>=20 >=20> Rename the user-visible config options so that users with CONFIG_Z= BUD=3Dy > >=20 >=20> get a new prompt with explanation during make oldconfig. Also, rem= ove > >=20 >=20> CONFIG_ZBUD from defconfig. > >=20 >=20>=20=20 >=20>=20 >=20> [1]https://lore.kernel.org/lkml/CAJD7tkbRF6od-2x_L8-A1QL3=3D2Ww13s= Cj4S3i4bNndqF+3+_Vg@mail.gmail.com/ > >=20 >=20> [2]https://lore.kernel.org/lkml/20240904233343.933462-1-yosryahmed= @google.com/ > >=20 >=20>=20=20 >=20>=20 >=20> Signed-off-by: Yosry Ahmed > >=20 >=20 > Can we just drop it right away? >=20 >=20The two cycles for z3fold were basically in the "not worth bothering" >=20 >=20category, since very few downstream production systems rebase that >=20 >=20frequently. >=20 >=20zsmalloc has been in use on everything from mobile devices to large >=20 >=20servers for years. It's been the default since 6.6 (Oct '23) for >=20 > zswap, and the only option for zram from the start. I certainly do not object, if no one else objects I can do that. We can l= eave the zpool code around for a bit in case a new allocator shows up tho= , just as due diligence.