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 D0B57C47DAF for ; Mon, 22 Jan 2024 07:45:30 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; secure) header.d=infradead.org header.i=@infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=WBu8+uXr; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4TJMhT3Spcz3cHF for ; Mon, 22 Jan 2024 18:45:29 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=bombadil.srs.infradead.org (client-ip=198.137.202.133; helo=bombadil.infradead.org; envelope-from=batv+f852a6472c07d339093a+7456+infradead.org+hch@bombadil.srs.infradead.org; receiver=lists.ozlabs.org) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 4TJMgT38WSz30YR for ; Mon, 22 Jan 2024 18:44:36 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=dR6yx6tN67WvcGk22bfKMLtWLGB0Su5dqNJD6Sk4JUQ=; b=WBu8+uXrPFN46pwRaBFARTzEwz BTwc4Pz8LPt1Fqn8IVxHsE4uzB01j9gUoHrZg1sOYkZYoAVys53D0DpJ8iSKFPpjTP8YS7AAaec0c 3mEQN405x+d3rJ3RuYaVyhVkhmJzmcDbV0S+m25vaJlc4nmjvu5Yw89rNHHf0lTGhOsgKsKVqOWV1 6W7K/KrBBAl+kJK4s9uL5uYbGtywtn8YWThJg3rcDEsPhRKD1LyF46FZTVbDjoezyc0jAsDenhi2K aoMnIZ9xkfG/2SiyVHT5Dkc7DlWhSmUKoGQJhKQhVBEJ3s/J1Cm5aCtRYaT6r+uASa0BJgXOZ72/R CI7KFzJw==; Received: from hch by bombadil.infradead.org with local (Exim 4.96 #2 (Red Hat Linux)) id 1rRowZ-00Atfo-0s; Mon, 22 Jan 2024 07:42:07 +0000 Date: Sun, 21 Jan 2024 23:42:07 -0800 From: Christoph Hellwig To: Yosry Ahmed Subject: Re: [RFC PATCH] mm: z3fold: rename CONFIG_Z3FOLD to CONFIG_Z3FOLD_DEPRECATED Message-ID: References: <20240112193103.3798287-1-yosryahmed@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html 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 , "Aneesh Kumar K.V" , Nhat Pham , linux-mm@kvack.org, Chris Li , Huacai Chen , Nicholas Piggin , Christoph Hellwig , Sergey Senozhatsky , 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 Tue, Jan 16, 2024 at 12:19:39PM -0800, Yosry Ahmed wrote: > Well, better compression ratios for one :) > > I think a long time ago there were complaints that zsmalloc had higher > latency than zbud/z3fold, but since then a lot of things have changed > (including nice compaction optimization from Sergey, and compaction > was one of the main factors AFAICT). Also, recent experiments that > Chris Li conducted showed that (at least in our setup), the > decompression is only a small part of the fault latency with zswap > (i.e. not the main factor) -- so I am not sure if it actually matters > in practice. > > That said, I have not conducted any experiments personally with z3fold > or zbud, which is why I proposed the conservative approach of marking > as deprecated first. However, if others believe this is unnecessary I > am fine with removal as well. Whatever we agree on is fine by me. In general deprecated is for code that has active (intentional) users and/or would break setups. I does sound to me like that is not the case here, but others might understand this better.