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 8966CC47077 for ; Sun, 14 Jan 2024 22:42:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 930F16B006E; Sun, 14 Jan 2024 17:42:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8E10C6B0071; Sun, 14 Jan 2024 17:42:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7818B6B0072; Sun, 14 Jan 2024 17:42:35 -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 667816B006E for ; Sun, 14 Jan 2024 17:42:35 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 2D1951A064F for ; Sun, 14 Jan 2024 22:42:35 +0000 (UTC) X-FDA: 81679392270.14.CB86E53 Received: from mail-il1-f173.google.com (mail-il1-f173.google.com [209.85.166.173]) by imf07.hostedemail.com (Postfix) with ESMTP id 5FED240003 for ; Sun, 14 Jan 2024 22:42:32 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="Esq56/2Z"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf07.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.166.173 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705272152; a=rsa-sha256; cv=none; b=hUsWmtviYBtbbA8ZNuDXa5lESiQYss1eqVVqebNSb99K6ATf0XJERKP94UJ+eycLnCnE0t a/CWejrPQ978vudi/O4Bm6of9d4uVe3aKXo2Sh/JV4lcLcH3QAw+MTwPdKTl5NKre+QeWP JVWcJvyoEz0jzGgkVvlbVy0BFcwmNOM= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="Esq56/2Z"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf07.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.166.173 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705272152; 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=XoLJM1YCWGjUlR9N5C5AV+mH39ndl7FYD4RDzU57JFY=; b=mO7jNZLfO1svJ1TnZzmKITaxaIrNEYQgUIjEdfMEn5dYyJolJIxtehAa2l5Le2sa0NDy0R Pq/cw9S5zGSN7lEG5e3WtK/+tjizUKFGHUiD0TxuUcKO37T4aST9Mc8Li6TvL9I2RkX5PS +RKMPBcAZvQMOAouZiiy//mDP4jyMOA= Received: by mail-il1-f173.google.com with SMTP id e9e14a558f8ab-3608e1d27ceso29659875ab.1 for ; Sun, 14 Jan 2024 14:42:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705272151; x=1705876951; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=XoLJM1YCWGjUlR9N5C5AV+mH39ndl7FYD4RDzU57JFY=; b=Esq56/2Z8OiGUDMNGtfqptQPf+h5t4CKiNRrXl7TaMlo/OdNakhB67y98BtZZNklee 4WTINzyLIiPB6eedyTimIyJbjaXFR4d1b0e2QiMPyOKIcKwT7hs0UJ0gQghEEYCu5YkZ 64S13cTzvtHlNs1WCro198EuMhHJxNZArK5PA4yu4o+I6TKq+6PX+K3biySYEDyijAbU Xpn1EDTLilaO+T4Fq+ryrZmz0hdhhk09ugcGzneDycx85lLq/cYGXapwto8z3NBWfh/M iKPy/L1ooXw4davPeehnpag3uXK40c5jeuzwOppb/zJODpl4+6yPbCrnh8dsBq3Rseeu J4ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705272151; x=1705876951; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=XoLJM1YCWGjUlR9N5C5AV+mH39ndl7FYD4RDzU57JFY=; b=cfQa+Msj2E05QmeUFr3FiufiyFkOKOVrJLeqRr24RMmTYCwM+WvcWVJXxHCreV1axk 3l3XmmFx6JHEmnGQbt488/qQ1/+UjcUZERWYUSxP6zuQeCHE+W1l0yiKg8DCOVqC7bm3 kmJ+5etv0unW6rXVPJOyO6WZSzFlKy/3Yn4c/hXM94FzJ/9NS1wax6Qdsrn+q+eQ68Sq UB2fGvAHRvuq2l+dpAdAE7mryS+ROto5ndlCgC6pY3v1xUzsO6mhFcY7Nfnt2VCsFDbx n1K85+zIC/tVOmjfEF55cxHGhrw22jLlhLLTwcrrvPEeuAeM1YrJ5jWyjcAQEI4kJJ5c gSGA== X-Gm-Message-State: AOJu0YxJ78x/oIA6moPJsD+ZtpCf25cl4cIKmIZ30m/8FZJDdVMv4sqZ Uno1/Tl29yckPfIiYWA28pGW+M4h55CgH1hFtec= X-Google-Smtp-Source: AGHT+IFc4YnzZDRRq3UdDjmWjnvvkoOaNnHCSsjrca54VMY2DX6cokwWeZGlhFAWBtidREnmbk5yja+calb/V2yb6xI= X-Received: by 2002:a05:6e02:188a:b0:360:7244:6089 with SMTP id o10-20020a056e02188a00b0036072446089mr7334277ilu.43.1705272151280; Sun, 14 Jan 2024 14:42:31 -0800 (PST) MIME-Version: 1.0 References: <20240112193103.3798287-1-yosryahmed@google.com> In-Reply-To: From: Nhat Pham Date: Sun, 14 Jan 2024 14:42:20 -0800 Message-ID: Subject: Re: [RFC PATCH] mm: z3fold: rename CONFIG_Z3FOLD to CONFIG_Z3FOLD_DEPRECATED To: Yosry Ahmed Cc: Andrew Morton , Vitaly Wool , Miaohe Lin , Johannes Weiner , Huacai Chen , WANG Xuerui , Michael Ellerman , Nicholas Piggin , Christophe Leroy , "Aneesh Kumar K.V" , "Naveen N. Rao" , linux-mm@kvack.org, loongarch@lists.linux.dev, linuxppc-dev@lists.ozlabs.org, Sergey Senozhatsky , Minchan Kim Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 5FED240003 X-Stat-Signature: py43eqtcqsu1g6raaserkofa964r35ck X-HE-Tag: 1705272152-909653 X-HE-Meta: U2FsdGVkX1/mgNXrPFy0KPg9DV/J8eceUyI27xK8xDmkT2GLmBGtdJobhg16we+cJuPhpKR+2U9uqSmUE6JzYrw+WFQdBBASlNiMC2ibJTXAt4kiP+apiJGrhy82J4VpTAHck+Exm28LU4p35nlsNXfuOgpWyv83k2gN/pbuFfIC8Nl/g7yBdA/G3KRdIGgJrpAtbu9ryiI1hr6ETNjDLi0u3fqREfZlL0qqYc+yTgVgxXXPmamlIVeuVEQoRms6ejwGrorApFNJ8j2vHzNpp36OcAz6pA9z8y4wELyUJP67/40xgUekh6O+0UIZdPN1LvlQ1qFJV6bgjf1JngQjdhlNCBbA1pUmR0ZqdTwo7H/iWJEWC3CUSlXDEuQ9Hc9RhPxESc1EBJHguh2Dy9VRp7/E5x7qiuG7eb2V7Xohv75WHKyvD2B5A65Ck1M333mpYDeIdvrwyEsF4Olk6VWu99vhNatWjZK94TIDp9mJBjhJINF//lrN4omXpT+N+4NBxmtcU4HtE25VwcDOs+o7djcLjfSpzjWVL8HsXeJUJhLyi3YzDk3Ti+uAEZk5HNmIdPMASuKlAeP5tSGnMrKZPMDibrTwC8vAo8DlZ+7QGcBo7kobhPWQLfmG9LGH2C+J64ySXmaUgwdqnRppj+9L5jUioY/ZkAQxPUlVGclgIavKivH1hQoYfPaMT3gl4y6452cP+UOZCLldGbvAj+7ovcM7NuK+4tEQcqA1WM4uopo5IVxiRwUKp/afIdG8CXkvGuZaNIeLE12Fjessos+6LpVBChsr2mm4kAIp1ofEMs5jlMs8mOl1xbMM1dfs/GuDL54p6TGC+zlkKK5Ro/Gd/0085gRvi25wVYzG6/KTRqv6kxgbEJ1tMG3mjWvFxb2/GmarFvJPy3FGar6RObcOMAoWIg2VKXlthh0j/gB/rDye1Jk5OMmKenBBtdwvgjDjqkJM6rdx8I0OXXMklGZ mmTXFxA7 J/Ie9Jfa3nYADGnI+H9Nq6tKa6GeBAOh7Bz1SE+bbLNp2y1cCgb8Zuk9rV2q+Vb7Hlt+8n3Es/oOkkaQcmnJP3NY0WhACRCLJzvuLpllArYWYlX1o+olkPIMc4wAyNwy2gYbtFzQewD04BfddTfpP0J0iqRl/XOSNvERZ7nvLhzcZW8l2uvfkrBiy7w3VvKIe8vORbZDsf9lkfL9HGT+NfRZVEFf/cMjp7wcs5PNLlEf8iEnm1baJB5EPZsXzEsA5A1QLOhXhNLnNSalFxzR2/32Su9WgjMmjrWR5wU5iK9Xn0qYNXey5iRvqixrsEnDDeEExFTxxmOVDzEyuKG8tf7C9Q3xuVAK7neMwieQsyVlNz8MVcfbRxap6wblqc+Ec7fJY3lh8IlfZBJP03TelKt/W6fC2T9vf7jFocVAe13KQPSYyUsbljaBom7y9RA3X5G2m 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: On Sun, Jan 14, 2024 at 10:49=E2=80=AFAM Yosry Ahmed wrote: > > On Fri, Jan 12, 2024 at 4:38=E2=80=AFPM Nhat Pham wro= te: > > > > On Fri, Jan 12, 2024 at 3:37=E2=80=AFPM Yosry Ahmed wrote: > > > > > > On Fri, Jan 12, 2024 at 11:42=E2=80=AFAM Nhat Pham wrote: > > > > > > > > On Fri, Jan 12, 2024 at 11:31=E2=80=AFAM Yosry Ahmed wrote: > > > > > > > > > > The z3fold compressed pages allocator is not widely used, most us= ers use > > > > > zsmalloc. The only disadvantage of zsmalloc in comparison is the > > > > > dependency on MMU, and zbud is a more common option for !MMU as i= t was > > > > > the default zswap allocator for a long time. > > > > > > > > Johannes and I were chatting about this the other day. We might be > > > > able to disable certain zsmalloc behavior in the case of !MMU, maki= ng > > > > it available there too. Once that's happened, we can outright remov= e > > > > z3fold and zbud, and have one allocator to rule them all? :) > > > > > > (Adding Sergey and Minchan for visibility) > > > > > > I didn't want to bring up the zsmalloc MMU dependency in this thread > > > to reduce noise, but that's also what I had in mind. Sergey and I wer= e > > > also chatting about this the other day :) > > > > > > I thought deprecating z3fold is the low hanging fruit. Then, once we > > > can sort out the MMU dependency in zsmalloc, we can go after zbud as > > > well. > > > > Makes sense to me. Should we do the same thing to zbud? We probably > > have even less of a case for it, no? > > Do you mean declare it as deprecated now? I initially thought that > would only be appropriate to do after zsmalloc has no dependency on > MMU, so that we can confidently say zbud has no practical use case. Ah, I misread your email. My bad. Personally, I'd like to declare both (zbud and z3fold) as deprecated. That said, no strong feelings here - as long as (eventually) we move towards retiring both of them. So my original ACK still holds. Not entirely sure which should we remove first between zbud and z3fold though. I was under the assumption that z3fold is slightly better, but that could be my bias for shiny new things showing :)