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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 2D5EAC4707B for ; Sun, 14 Jan 2024 22:43:36 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=foEpoX1N; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4TCr0R2t4zz2yk8 for ; Mon, 15 Jan 2024 09:43:35 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=foEpoX1N; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gmail.com (client-ip=2607:f8b0:4864:20::12f; helo=mail-il1-x12f.google.com; envelope-from=nphamcs@gmail.com; receiver=lists.ozlabs.org) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4TCqzM4z23z2xgw for ; Mon, 15 Jan 2024 09:42:37 +1100 (AEDT) Received: by mail-il1-x12f.google.com with SMTP id e9e14a558f8ab-36071f2181cso29160165ab.2 for ; Sun, 14 Jan 2024 14:42:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705272151; x=1705876951; darn=lists.ozlabs.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=foEpoX1NWC9iuOuYZdCziG+DkvzE53gonGRROTu9uk2NJL33zJpBcrqXfLdfdWQzXp /r3sF0U1WCNdHkVDpRMBDrCrvBn8aH9cGrQUJ8TjKwVfFsZTAII0ghAxfm7yUCTz1OvQ sr6zf2nSZmlIm23xoYx/f7whvbn7IkfQB/tvlBwT3EPUtE5/lerhbDM5RxOZPVgkUDB2 rltJhS8WDXbbGTxqdwhRqbwT2ZakDnxV8mWRDff3YY6kcOXeH4ICQqOaYg7s5Ou+fgeO LVeZEWRiyxV2k+G9j9DaOvWuIub3HxfRBF2BbIYPWC0Q4JLqMKzch88x8QHo2IFUkcLL 7+oA== 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=Nb9GRTEK0JeQSS2HIU5Y3v+rANrhI4G19zGcUydUvpZXoqGeUEHy40cElKqr7+v4/V k0mpPeNfvtoeLHP+W7ag3B/CsKUZjClb0DrtZ9nE+Z23TRaLD1Zut9BZRpPJmnpXleGo 9txdNtM+Hjz01R878sjs1/Z8unFoCVCrxrTiIN6R2+LtHRNsiIJrFk6XVJdtTTnBqAct Z2Eje4ogFkkE+pMpRnei5ykz9+Fz43L1bsM3ygiKbRLS7t/W8HRaEEyhfIEbQQBkQ20E LMMD6GTOZ0PzZjEKsJ9ciQLevvdBNBUYsLGAQVNmtcBAJ5NbmwtuPhp3F9xcGw2rY0yN fGOw== X-Gm-Message-State: AOJu0Yy2xaa3W6FX2VbK9BB8mco2/8yipitCS4EK1TrlWhzuNM9PBd3h JD1tkG46XJOMUEcWHNh0FUSjxzZ0qNNED+qbDTM= 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Miaohe Lin , Sergey Senozhatsky , Huacai Chen , Nicholas Piggin , "Aneesh Kumar K.V" , linux-mm@kvack.org, loongarch@lists.linux.dev, Johannes Weiner , "Naveen N. Rao" , Minchan Kim , Andrew Morton , linuxppc-dev@lists.ozlabs.org, WANG Xuerui , Vitaly Wool Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" 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 :)