From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) (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 9011B156669 for ; Tue, 28 Jan 2025 10:14:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738059293; cv=none; b=DDF374W9lzJ53XfiDRVSjy+D5miaxgmVYlFl1m8Ao+MQY4YTyVXxwWuinjipVeYY5PwtAoE8jXWMOVdc7h1yrAEGqBCmSxzagD4Z34dhGqsMUt70oKeVIY2IS1+rCmiKD/niCLghWLJt15w7DUJ02XcYvMKQPrGSNDPSTaZV7bc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738059293; c=relaxed/simple; bh=5lvs8HiG7TGF6/vHKmJWpTOuUvsPsw8S5GITAUAn4MM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=KOQ0uVFbsI7uJN3z/Ij232PXQAEJK5VukD7B8Ploy/VL58BOFP+5JrJJKD3ma7ufrbPOKLLFEhA1Tv1JHjnrxs5iOdElOLd78X7BTicoBGhOSFpEBNLOaquN8M0G7eYG1nHKUAA9hT0FRy5wZoF/YjOP67lxOyDy0Bgo04W6tG4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org; spf=pass smtp.mailfrom=cmpxchg.org; dkim=pass (2048-bit key) header.d=cmpxchg-org.20230601.gappssmtp.com header.i=@cmpxchg-org.20230601.gappssmtp.com header.b=TcMAwhqs; arc=none smtp.client-ip=209.85.160.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg-org.20230601.gappssmtp.com header.i=@cmpxchg-org.20230601.gappssmtp.com header.b="TcMAwhqs" Received: by mail-qt1-f174.google.com with SMTP id d75a77b69052e-46fa7678ef3so23697191cf.1 for ; Tue, 28 Jan 2025 02:14:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20230601.gappssmtp.com; s=20230601; t=1738059289; x=1738664089; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=T+OJo5OrtdbsUfbDREZKvi2Xm/rwCKQG5dGU4viVWio=; b=TcMAwhqsNErqfBuZi8BUsAutMfGY7minz7NrfQK8VgOxbo9IrEY0A+YlzxpjOS50tS Jlu/cVHZxsd3eTfvQZEWghvwg8U+IblQlwg2CM6DexiKe4R2su5DmuiG2p67w8hS2RL1 PhYZSXKTEVqyT+YXYVCLTk8eoXXQckB1hgLqUUj6owLBAigHMFRwa99uNdGyeTe/7171 F34csb4gAA7sGi4UYXHO7JlGjlhc97EObD5tSf6BWDxzFdT+BZLOlGL14YZJRxm0r2vp Oiyyqex0N7pWaTjmoy0O4vZWddaesycLFVEqjX8G/iQ/7CjnHu3VumRHpSUfDPXTAgnW ugjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738059289; x=1738664089; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=T+OJo5OrtdbsUfbDREZKvi2Xm/rwCKQG5dGU4viVWio=; b=cLS/Xad53tTG+HMQyJOUxgAB8qEWgMUOfiK8klLDd5M8ksHILSysHlVQGpJdDom35/ dpdHCv1Wby9v5s+UiWaI0GuPeCJm1cwpDm0NezeXg+a7suaF8trxWTc7lNSsgW7W9bRV jM03CV80MG+G1AlEx2/rQF//do6A+xoeFY/jVo9b7DaOlCmDwQt2Csj50hryDYBuQ/EM 5G2bLu4cov+p/FdI0pIuiAq9gSSwFXD5/qxssz7+8JLw6dfXqWyxPF0k11A6DxIrnP08 gC7nZtDVaKcmZI0t2KrGLvrquUUAJSZIB+AZ8HvtgEf1tmNfboUi4hD/jcbfXoWpWqky +8VA== X-Forwarded-Encrypted: i=1; AJvYcCVnJZXlDw4qC6c04L77wgqI3IdX0AygPY8gdm2HQwtoM5bdNzTB1pV+Hn4YkQCfm33BbaeM8F21j+iqrrI=@vger.kernel.org X-Gm-Message-State: AOJu0YzNzoTEfIfekrkHxOMymSfjju1e4EMdHFDZ+XQ/Tq8sfXJslSp1 u3+ArjhaW7W+DaboYHRw7xn7k+OeE8RIinVjP5wphEBlGKLeovHFg8S7NS16OzU= X-Gm-Gg: ASbGncsVaIqxYa8o30SVTd0MF6QH3OjqTFcXfvBowNNoZmvGbu9drSlBbCVAFDvOrec oJK2p4SYLRaTlS148oGjF5ikEMpYIsJ5ceWd+715N0vX04E6wuG9nDiBOwSGeaQKC04wVRX7H12 m8i5Vs8LThe46eMT9ha4s0JuiUKHOdMLywjPV5VoDwxIzBjeu71W+Jekg5W/9v+FCKXcPc1XP6D w2ROLC30pNxupn+PRvUfCJN0HljfY3K+9GH16nV4ZO7j6EcAzwwJGQhqmg0lFFN33dh3wX9zdXF wbBP+zFPhyLmVQ== X-Google-Smtp-Source: AGHT+IFALe6WVLHYMuH9iT72w4NXQewmaC4+fVCySImFG7ZmNiWWkYcz7G2f61JtCoHmT0Mt8hGVxQ== X-Received: by 2002:a05:622a:52:b0:467:6cce:44ba with SMTP id d75a77b69052e-46e12b96babmr592982961cf.43.1738059287990; Tue, 28 Jan 2025 02:14:47 -0800 (PST) Received: from localhost ([2603:7000:c01:2716:da5e:d3ff:fee7:26e7]) by smtp.gmail.com with UTF8SMTPSA id d75a77b69052e-46e6689dab7sm50327711cf.44.2025.01.28.02.14.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Jan 2025 02:14:47 -0800 (PST) Date: Tue, 28 Jan 2025 05:14:42 -0500 From: Johannes Weiner To: Yosry Ahmed 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 Subject: Re: [PATCH 1/2] mm: zbud: deprecate CONFIG_ZBUD Message-ID: <20250128101442.GB691108@cmpxchg.org> References: 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=us-ascii Content-Disposition: inline In-Reply-To: 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@mail.gmail.com/ > [2]https://lore.kernel.org/lkml/20240904233343.933462-1-yosryahmed@google.com/ > > Signed-off-by: Yosry Ahmed 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.