On Mon, Jan 27, 2025 at 11:58:21PM +0000, Yosry Ahmed wrote: > The zbud compressed pages allocator is rarely used, most users use > zsmalloc. zbud consumes much more memory (only stores 1 or 2 compressed > pages per physical page). The only advantage of zbud is a marginal > performance improvement that by no means justify the memory overhead. > > Historically, zsmalloc had significantly worse latency than zbud and > z3fold but offered better memory savings. This is no longer the case as > shown by a simple recent analysis [1]. In a kernel build test on tmpfs > in a limited cgroup, zbud 2-3% less time than zsmalloc, but at the cost > of using ~32% more memory (1.5G vs 1.13G). The tradeoff does not make > sense for zbud in any practical scenario. > > The only alleged advantage of zbud is not having the dependency on > CONFIG_MMU, but CONFIG_SWAP already depends on CONFIG_MMU anyway, and > zbud is only used by zswap. > > Following in the footsteps of [2], which deprecated z3fold, deprecated > zbud as planned and remove it in a few cycles if no objections are > raised from active users. > > Rename the user-visible config options so that users with CONFIG_ZBUD=y > get a new prompt with explanation during make oldconfig. Also, remove > CONFIG_ZBUD from defconfig. > > [1]https://lore.kernel.org/lkml/CAJD7tkbRF6od-2x_L8-A1QL3=2Ww13sCj4S3i4bNndqF+3+_Vg@xxxxxxxxxxxxxx/ > [2]https://lore.kernel.org/lkml/20240904233343.933462-1-yosryahmed@xxxxxxxxxx/ > > Signed-off-by: Yosry Ahmed <yosry.ahmed@xxxxxxxxx> Can we just drop it right away? The two cycles for z3fold were basically in the "not worth bothering" category, since very few downstream production systems rebase that frequently. zsmalloc has been in use on everything from mobile devices to large servers for years. It's been the default since 6.6 (Oct '23) for zswap, and the only option for zram from the start.
