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 F0FA5C3DA79 for ; Mon, 15 Jan 2024 20:02:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 56E316B0085; Mon, 15 Jan 2024 15:02:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 51E436B0087; Mon, 15 Jan 2024 15:02:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3E59F6B0088; Mon, 15 Jan 2024 15:02:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 2F15C6B0085 for ; Mon, 15 Jan 2024 15:02:13 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id F25CF160596 for ; Mon, 15 Jan 2024 20:02:12 +0000 (UTC) X-FDA: 81682616904.12.4F56957 Received: from mail-io1-f53.google.com (mail-io1-f53.google.com [209.85.166.53]) by imf11.hostedemail.com (Postfix) with ESMTP id 0AA6A40029 for ; Mon, 15 Jan 2024 20:02:10 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=PWDA2iLr; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf11.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.166.53 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=1705348931; 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=WbP8f68FneqS35iMSb6Ai2Krkdv9R7DQjS6AqJROA3o=; b=3M9MiaxqLKUf9S7suv06X986GGEgQ6RTqMNh/6veIRtbGprmfiHp6p53kGJPRZ95ZPZJkX Ll2tdtK7yg9devdr3SbOrkEtNGhGqrXQgcC4rdXX5silSbWvJJxmBGoIrsRYHkpLJIEvwW bzQxVO1Q124/6RQNZgcjcEhIinYa78k= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=PWDA2iLr; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf11.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.166.53 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705348931; a=rsa-sha256; cv=none; b=zoJ6cy8/Mz4NTPfiS06yyTYscsEJvH5FvBNVEf7QDjR8MVkfZrtC23BajzhCdsTp4FL0JK VxHdixNLa0ytbuLG+H3ldcnE8pjgduVqkAm0tPs6bQR3kB2U6qJyyEIm+DWFQ0lkJbVjZW APP+T5X6S+DTv/cfBGQvQ9mbdbojK4U= Received: by mail-io1-f53.google.com with SMTP id ca18e2360f4ac-7bee87b2f5eso168101539f.3 for ; Mon, 15 Jan 2024 12:02:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705348930; x=1705953730; 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=WbP8f68FneqS35iMSb6Ai2Krkdv9R7DQjS6AqJROA3o=; b=PWDA2iLr4Dyrn8lHmLaAv5iD7vktPEl0bvlwakqPIDVn7zy5XOlXb2vCrzELHQZKqB 8jNEPx3jT6WxyXKyfUgoFwP6e6XkX0IMGfs5kl2zdlGriKoAMhGtCtQzVCdd5UkOoDU3 X2sWoK/65HnQJL79vj3RlGgqeXPKxGlW1v50l/qgfKS4FrWkylZWxeajKPtGTyCUg8oM AuJUWhw37P+Uc6oH8hJmAQctHSvghlpfZzKn2op6URe5goaps17Ofqm6lWVqJEZriCud VGIGekWHbB8q4wnyAXp4FT+m6VQKrZMVXIrxWC1Vu9kAqdruCRqQSVNLuIxrYpbYfHV5 Y4/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705348930; x=1705953730; 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=WbP8f68FneqS35iMSb6Ai2Krkdv9R7DQjS6AqJROA3o=; b=igISydTtfyY9E5WisZFYGgPWkdjyACHxL46J1iI/Hlt/I+D+dSDKDfd2uCXjYHnAvz VQxgBM4FiQX/vt6gAgKJGXsjnyFbVMW4mq3BAwjAKyt8PMpC7tK4ZWexdC0wXSiuOX6a QlI5xbxSLkfgt8+J4jxyeyZ8okf4cvUhkEsCZoZi8dzTphwxfMeJS/M3pp/+VW3B1afK 5wuHD73UG/32DOjlo+F+5NypV76v4nZa5uSWfe5dN8dxB6oXi2qulN9emQJteoUcjSAr twQoae2xCNzaw3clkk3mD2Wyphj5Sqi+bzD96EmXbd8Qozimnhrz3EnpfrGcw3Cw2ztc gJmg== X-Gm-Message-State: AOJu0YzhY/OO0YjUCv1KWUtx7znmI/dk88Zrct/VEYTXgIQcdiVbUZhT ewmmd3ff13rUkxLTBgm6NddhzIyWgmp1UFtTw28= X-Google-Smtp-Source: AGHT+IGoOdW+aeoc91UwOnpg9hVQGt8tI8/aToJQfADXkg0FmKNY58cZw1wiDMwjHJuDhjzyx1g4Ij03JmdRrdylacs= X-Received: by 2002:a6b:f017:0:b0:7bf:3b15:a4b8 with SMTP id w23-20020a6bf017000000b007bf3b15a4b8mr2795535ioc.37.1705348930027; Mon, 15 Jan 2024 12:02:10 -0800 (PST) MIME-Version: 1.0 References: <20240112193103.3798287-1-yosryahmed@google.com> In-Reply-To: From: Nhat Pham Date: Mon, 15 Jan 2024 12:01:58 -0800 Message-ID: Subject: Re: [RFC PATCH] mm: z3fold: rename CONFIG_Z3FOLD to CONFIG_Z3FOLD_DEPRECATED To: Vitaly Wool Cc: Yosry Ahmed , Andrew Morton , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: 5jijey7bhjbapym83x3fhz6dkchz37ey X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 0AA6A40029 X-HE-Tag: 1705348930-303089 X-HE-Meta: U2FsdGVkX19zT5fQxNcfpmCHlQre43vr+o/QN7d+nAEqiPM+zRLKrjpahzo+feZ0WH0uu2+RESoGYdpPXVIINC1JLlx82ZlcFiSG26LAVob2xG8a/4FEHhcC/teLJn4Zu1x8FOxcuol5isMWBiKmd2fmBKqhw1gke1J6H2CIY6+hqCLQjWBkd5XlVabYQqZSC1s/mxBZAuepO/EYF/nsbsJivFoFfJSy7CVHJXQqjs3TCbAvbUrvp1l96L8zJumQr65Sc2lUiYn/hKveo0/Mq4ulI1bkeLwxH82uPJ/tEaspqS76ha7/dpbV6PSI5I+fPt/IVnagIhhZpSFyJKiKGZZezW8BrgUjxF53vLYF1PR+Km9HXDK+v+OzRQOYofwem8Uzs5I0s7vIGRhmsMhWvEMcc8LB8np9WA1CLVhZy/Gayi00YW6N7qel6pUy7FXjmVhz96oT6NgT9vEZaWgLRfZq5DL8VYbs1Sa8CzKw32SX1c/0vb1lAJAXKsjYrw1GvzLnSLIvx0aOPx83i+6odhqJGe6o+ZjyoQ5QSP0WWTizHktWE2zDyhmuvVCcusGp1m0nW1yOwyKKLh04DpMCz37ZnYbYLdF0njulEEdymRszAUqFdOm74iSjL+CnHLCJnTO/vqvU1DFuFwCLdRuOofMGf6laOkGsQdNaGy7nDwc9lSARiJunE4mDEXhvEKdoMcBpc6aci9pevjfLXJEAw/vPpYK4b4MWemZIHYEuPOXmIHnOjHr7l7NKjvb1DEC7+iJMxsbi+MARweGeNT04MPRLPfnHgoQ/6YlDaESwzFROQM19RBKXB+aBRQ3yBNCfbmtEwc1GFzIK3XIE4Fc50eNB/mYiVcV+IS8LaSqE9kdo/pIMlS9211+nqPaoNJBzuO1IiivyoGN/hhKSa5tHKEGY/azrCZEZJiIeTQNRbtQo9vWkZOJ5pnx2wLiwDDGZNrShAgJp1Y+Ar8lsP7j htc6ML/U ZKDxNUfa8OhkZVY7PpXmevP76OPqfjhv2Cl5cjbghh8dhSI6qohAnMHNqBVlBzRQTcTG6EEdO44iYLfBlwLsxIaryvgwwf0WYY1RIaY/rC070p8xotqjaEhl9H0kJts/Z1v6q6sWsIB1tdh5sf8LNU8jbyYv5HPJ88mLqXAr4XNUCjYVfBgrcOVy3NQMs8+i79pJN8K3xWgr0mf4HnLdGwuOIrcsEV+NKOMXD+AnoldYMr8mq5tfR2TebN3yUTGx6K1VK1VwCALwy1ZvsaGZEUkgHJ2rJbF9e3zhGdbJIRZH1C6x5h6P8dpgXE1IeHB/M734mg26aFt1M44W2JBiMyJQeU1YcnBskw+SepZVpeN3uRi85YlmnGLeBcgXhmz1FYuADH0KRKS0eaG6L5tQaG7UOP8Q6SvHR2355WFLnmhXFP+8arrhjC2y+Dq85EQMkEGp9gXUELibQ/lTW+kFP/F8cQugy2c+Vm9DVjxeXfB32aoy8p3EHiObqJgm23h83aCm6bY6In/6wHI8IA9dtAGrAHAZNLlf18hQcFZMkJlYOhNpaqs+iJt/30Fm+Y67D6mIF 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 Mon, Jan 15, 2024 at 4:27=E2=80=AFAM Vitaly Wool wrote: > > On Fri, Jan 12, 2024 at 8:31=E2=80=AFPM Yosry Ahmed wrote: > > > > The z3fold compressed pages allocator is not widely used, most users us= e > > zsmalloc. The only disadvantage of zsmalloc in comparison is the > > dependency on MMU, and zbud is a more common option for !MMU as it was > > the default zswap allocator for a long time. > > > > In hopes of having a single compressed pages allocator at some point, > > and following in the footsteps of SLAB, deprecate z3fold. Rename the > > user-visible option so that users with CONFIG_Z3FOLD=3Dy get a new prom= pt > > with explanation during make oldconfig. Remove CONFIG_Z3FOLD=3Dy from > > defconfigs. > > I believe that having a single compressed pages allocator is a false goal= . I think it should be, where possible. Having fewer code will lower the maintenance burden. Of course, this is not always possible, as one option might be the best in one aspect/use case, but not so in others. In the case of zswap (which is the only user for zbud and z3fold), it seems (to me anyway) zbud and z3fold aren't really serious competitors for zsmalloc anymore (outside of that aforementioned !MMU case). I'd love to hear some use cases if I'm mistaken though :) > > > Existing users, if any, should voice their objections. Otherwise, we ca= n > > remove z3fold in a few releases. > > At this point I NACK this patch. We're about to submit an allocator > which is clearly better that z3fold and is faster that zsmalloc in > most cases and that submission will mark z3fold as deprecated. But for > now this move is premature. Ah, this sounds promising. I'd love to hear more about this new allocator, and once it's available, experiment with it internally too :) That said, even at this point, does anyone actually use z3fold and/or zbud, and cannot use zsmalloc? If yes, then yeah this is quite premature. If not, then we can mark them as deprecate, no? Introducing the other allocator and fixing zsmalloc for !MMU can be done in parallel - we're not removing z3fold and zbud anytime soon even with this deprecation notice. > > Best, > Vitaly > > > Signed-off-by: Yosry Ahmed > > --- > > I have limited understanding of Kconfigs. I modelled this after commit > > eb07c4f39c3e ("mm/slab: rename CONFIG_SLAB to CONFIG_SLAB_DEPRECATED"), > > but one difference is that CONFIG_Z3FOLD is a tristate. I made > > CONFIG_Z3FOLD_DEPRECATED a boolean config, and CONFIG_Z3FOLD default y > > so that it is on by default if CONFIG_Z3FOLD_DEPRECATED is selected. I > > am not sure if that's the correct way to do this. > > > > --- > > arch/loongarch/configs/loongson3_defconfig | 1 - > > arch/powerpc/configs/ppc64_defconfig | 1 - > > mm/Kconfig | 13 +++++++++++-- > > 3 files changed, 11 insertions(+), 4 deletions(-) > > > > diff --git a/arch/loongarch/configs/loongson3_defconfig b/arch/loongarc= h/configs/loongson3_defconfig > > index 33795e4a5bd63..89b66b6c6a1d5 100644 > > --- a/arch/loongarch/configs/loongson3_defconfig > > +++ b/arch/loongarch/configs/loongson3_defconfig > > @@ -85,7 +85,6 @@ CONFIG_ZPOOL=3Dy > > CONFIG_ZSWAP=3Dy > > CONFIG_ZSWAP_COMPRESSOR_DEFAULT_ZSTD=3Dy > > CONFIG_ZBUD=3Dy > > -CONFIG_Z3FOLD=3Dy > > CONFIG_ZSMALLOC=3Dm > > # CONFIG_COMPAT_BRK is not set > > CONFIG_MEMORY_HOTPLUG=3Dy > > diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/config= s/ppc64_defconfig > > index 544a65fda77bc..d39284489aa26 100644 > > --- a/arch/powerpc/configs/ppc64_defconfig > > +++ b/arch/powerpc/configs/ppc64_defconfig > > @@ -81,7 +81,6 @@ CONFIG_MODULE_SIG_SHA512=3Dy > > CONFIG_PARTITION_ADVANCED=3Dy > > CONFIG_BINFMT_MISC=3Dm > > CONFIG_ZSWAP=3Dy > > -CONFIG_Z3FOLD=3Dy > > CONFIG_ZSMALLOC=3Dy > > # CONFIG_SLAB_MERGE_DEFAULT is not set > > CONFIG_SLAB_FREELIST_RANDOM=3Dy > > diff --git a/mm/Kconfig b/mm/Kconfig > > index 1902cfe4cc4f5..bc6cc97c08349 100644 > > --- a/mm/Kconfig > > +++ b/mm/Kconfig > > @@ -193,15 +193,24 @@ config ZBUD > > deterministic reclaim properties that make it preferable to a= higher > > density approach when reclaim will be used. > > > > -config Z3FOLD > > - tristate "3:1 compression allocator (z3fold)" > > +config Z3FOLD_DEPRECATED > > + bool "3:1 compression allocator (z3fold) (DEPRECATED)" > > depends on ZSWAP > > help > > + Deprecated and scheduled for removal in a few cycles. If you = have > > + a good reason for using Z3FOLD rather than ZSMALLOC or ZBUD, = please > > + contact linux-mm@kvack.org and the zswap maintainers. > > + > > A special purpose allocator for storing compressed pages. > > It is designed to store up to three compressed pages per phys= ical > > page. It is a ZBUD derivative so the simplicity and determini= sm are > > still there. > > > > +config Z3FOLD > > + tristate > > + default y > > + depends on Z3FOLD_DEPRECATED > > + > > config ZSMALLOC > > tristate > > prompt "N:1 compression allocator (zsmalloc)" if ZSWAP > > -- > > 2.43.0.275.g3460e3d667-goog > >