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 65099E7F12F for ; Tue, 26 Sep 2023 21:26:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E8E098D0051; Tue, 26 Sep 2023 17:26:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E3E3C8D0002; Tue, 26 Sep 2023 17:26:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D06B98D0051; Tue, 26 Sep 2023 17:26:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id C0E7D8D0002 for ; Tue, 26 Sep 2023 17:26:44 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 92946140942 for ; Tue, 26 Sep 2023 21:26:44 +0000 (UTC) X-FDA: 81280033128.20.C5E5CF6 Received: from mail-qv1-f53.google.com (mail-qv1-f53.google.com [209.85.219.53]) by imf05.hostedemail.com (Postfix) with ESMTP id 7A1D3100006 for ; Tue, 26 Sep 2023 21:26:42 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b="qRCGqcZ/"; spf=pass (imf05.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.219.53 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695763602; 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=muLZH0eItTClOvNm2BECD1Xlt1dVjs1Gh1+6BZ2wAV4=; b=8EUdJriJbelmOIyIjXULp+zUrZMya9eBV/3GfhgfAT+TGxE7VX4rRFhb2nyPFU7HOB3Nm4 QM3Wp9ShO/CmyIStOwLwxsFf2DdwBymToJ8NwkUS4ybOSD+ICwVchK1ytBoTahc2mZA27/ bw3Ytm1kTKXEv8p6QP96t3SDSedJxs8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695763602; a=rsa-sha256; cv=none; b=SJKNrZCPyma6AN3teto2KFi8O/zu8H7aUZ2f3/ZoISfoIELBODkaTkWB7P3nezy+MZ0ivq 8WD3rt+epvTJa/2ISqKgJYBgSwdDHpwcGAOOfLMie7HK2n8xr6HoGlbkGFwt2xYwDxryoc iUBdWogGfm9KdUOESBZWzKPmS+sD+2s= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b="qRCGqcZ/"; spf=pass (imf05.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.219.53 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org Received: by mail-qv1-f53.google.com with SMTP id 6a1803df08f44-65b0e623189so26743496d6.1 for ; Tue, 26 Sep 2023 14:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20230601.gappssmtp.com; s=20230601; t=1695763601; x=1696368401; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=muLZH0eItTClOvNm2BECD1Xlt1dVjs1Gh1+6BZ2wAV4=; b=qRCGqcZ/NMnJ+qSn8H86hoYUViFWFITM+RmBaZ3xO0/HfaK+WCMWxoCx5owGBvdHsT /3Yl/rHyt3D/WqztbOOapYYjffz+3u6OEvJ8rtB6DmDZmyU+AY1AtqPTQqMmd7AuRMIO kR2BRUWq3k8tybivO69lc6UMSuAEQf/I2I1qOfDlZ1ndVB//uNAvf6Euy73e5vLFtQqz vTLw4O2/eOln1lJ+jld9Cb9n1c0Pg7yue/w6azr2RCcEXxb8YYTdu0sdqOpYXt32oe7A dHSwz5kGkee3gk294KvyzLlC31xDdHGopGlbizFdUPcvE27g3vRXOqL4al4yGhna6DWg QBKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695763601; x=1696368401; h=in-reply-to:content-transfer-encoding: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=muLZH0eItTClOvNm2BECD1Xlt1dVjs1Gh1+6BZ2wAV4=; b=qnJ1yiq8WlVtDgupCLUxMomm7CfW6xnQnZlVJpE0Hv3aqP6gaD43zLoa8dGhXTlaqi wt2GraI3gbCWdLtI6sHHZ9cCfXIPB2XMsvgBfym/eWp/Idi0XIcuOJClJfuyNxfx5YfP FiiCVX9q91+xfncqhAIwfgZcFSGhiGZsxcvFAnseFng0IwweSnTFitu5yJJIZFBk6FLD eUpTsxXT6i3f/r/vFopkSJU380LJluhlRDBbfMNhK0NtxMQugiXYeKhMRd6zKmCPIS/V eWzNl6an9uOs9DhhzasbAC3Zri6hQYktahXYeleQadXtgM5iQtrTegxunajJUIWe5fsA wd+A== X-Gm-Message-State: AOJu0YybNE0beplKe2VHoE5Wpq9TZwR8qHZkUeeRZMu8Z/36aUhj0Irm 2ajkWc/tKWNYhzhviUFk8OyxSg== X-Google-Smtp-Source: AGHT+IHzmW+l9cgN4DlbGDZUaAp8zkUi3pgbXJykAuA7GiC0MGLqCWdJ+CpuymwGwbW+p7jrJ0Godg== X-Received: by 2002:a0c:f053:0:b0:658:396a:444e with SMTP id b19-20020a0cf053000000b00658396a444emr145795qvl.7.1695763601492; Tue, 26 Sep 2023 14:26:41 -0700 (PDT) Received: from localhost ([2620:10d:c091:400::5:ba06]) by smtp.gmail.com with ESMTPSA id r13-20020a0cb28d000000b0064f4e0b2089sm1478849qve.33.2023.09.26.14.26.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Sep 2023 14:26:41 -0700 (PDT) Date: Tue, 26 Sep 2023 17:26:40 -0400 From: Johannes Weiner To: Nhat Pham Cc: Christoph Hellwig , akpm@linux-foundation.org, cerasuolodomenico@gmail.com, yosryahmed@google.com, sjenning@redhat.com, ddstreet@ieee.org, vitaly.wool@konsulko.com, linux-mm@kvack.org, kernel-team@meta.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] zswap: change zswap's default allocator to zsmalloc Message-ID: <20230926212640.GC348484@cmpxchg.org> References: <20230908235115.2943486-1-nphamcs@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 7A1D3100006 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: r9fqquthtzq1k86bppmbdru9orb8pejn X-HE-Tag: 1695763602-828966 X-HE-Meta: U2FsdGVkX1+vc+pxyra8Fac9ST/ZcvBbLQafzj302O3filTq05RZcgVayl83VT6Rlz+uMNqAeJuBtOokHY+2AKw9CramI4rH4RqwFclbQkMjOw+1mRQYyaQMKSDclsf9/EcpWeMmUhPpU/g9AcoWbk+DOmHzQutVW7nJvay03HPSNOhIET2aNuK+45YLIZfE7P4zdzizCYlrnBpJDh2f71bHNzFoqDkM9splGQF1fCUz0ZvN1jOPje6WVIsC8JcXKKZ3MKMfO3S2GM6GRS1Ghew4m/m6vWnDSYUAvUSNC3ebVvgBxnsuZQ0AOC+el2szgDMMHQRWxXT876/PA2hi5mgJ2U7XUr2mWn4u4mIW8dguwGowV1AbEjxv/6VQ1QZ5d/20AMzPL8fVp1HE4IaYhEqsjGhb8MaKDmgmYdP84T5yW6eqlC56rJJUUyJBL8fMxfY6aPxMo6RyRQLlMTHj+ST1CweVQKJZ3jTSJnEX94DKmr11HbTspRWLc1vvTwfbzLhUIBaPK7vXdlpigb/FLDy0+NHeHfwahcNWgVArgYQ9idxpyejaeNwqkmCNlutXfxawPnuvpmFCOPZhISf7e9CRvp5OHgIqlL/n7SW33hrcEctIoL8/oiKzf+PEv/J06+P/j+taUrgy6G/2OULGfgzKV4L9QrKvtDk0tcX1p/m1fjCVtJrO9QL8uuMGxXvwq9Lesqb2VqXh/94hVgnHaKIFtZHvXP5bZAYGGbmo6h40B4qb+6oEqC86MFw4bVe6ZCFJzorzGtLO7Hay5avnZ/CLmRk1m8PV6oOnH9eZRky3Y5gI8cknOsmqLz03ye+3pRyVsGYEqpoZr30XoIT5zVdlC54kaBz4AEcFcZp1YnB3kUwFWzB1G5uJdvqtYk0iOd1XtWZDVvVICpnzlVNs+Y3f+KH6MKoiPnpLVYPiB8zSXuQIVv9B4wUtoOKeQNkON3DHKJqwagYEWXViW37 +Qz2aKr2 7Mv+SJnLWEVUotllMa/0aSfFEbcO8YM5Evg4t/FjqoLgCns+xtfAVg+wPc6Y8vysXVBc8G7jgWNeotcRfWuWSyxSN7pGTFkB97xjpXu2IuF95PwCF0KX/Uagjv5rLdrCeWuJgnhLDOR/lJGMsO0KhZaQ8HBxPBnirILA6MkDflWmlEGkcgep/CKa3d7l2UuWuQYUuHlDFLQ3jCqVRQqR5G6y6O4p/FCxNHUpWG/yDJ2qnEUC2Iwt0RC0NkVtnQKQlo+RB4xGNA+pheALxsv1oq9g95qJWwYEF/o4gKpkL5sJb+xMcNy2I676mAmWx6srsB84ynwDRAgtqup6UxcesXxw2M1XBgKXkBIk3BzC3XHlyqx92KGBFJqUBFvy3SjzohcyPcOeEB4wmno7c5wwW0Q29vsqwROry5lGZD29TUc6Pary/FFzy0zCvoPHm6R6HDLOlexGuRHp5D6iR7UE5qVmPJH5iZYQSMkAK 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: On Tue, Sep 26, 2023 at 01:06:13PM -0700, Nhat Pham wrote: > On Tue, Sep 26, 2023 at 12:29 AM Christoph Hellwig wrote: > > > > On Fri, Sep 08, 2023 at 04:51:15PM -0700, Nhat Pham wrote: > > > Out of zswap's 3 allocators, zsmalloc is the clear superior in terms of > > > memory utilization, both in theory and as observed in practice, with its > > > high storage density and low internal fragmentation. zsmalloc is also > > > more actively developed and maintained, since it is the allocator of > > > choice for zswap for many users, as well as the only allocator for zram. > > > > Dumb question from an outside, why do we then even keep the other > > two allocators around? > > > > Maybe legacy users who explicitly configure zbud/z3fold? > We have a couple internally, and have to manually undo > those configuration after we stop compiling these 2 > allocators. > > But yeah, I don't see why we should keep these 2 allocators > around. Time to deprecate them? :) I agree we should try to get rid of them. The best reason for them I can come up with is that they're more "lightweight". But I'm not sure that pans out in practice. Even if loads and stores are marginally faster, the poor density means you have to reclaim more/hotter anon pages for the equivalent reduction in memory usage. In most cases this will increase the overall amount of ongoing paging. That should quickly dwarve the minor advantage in per-transaction overhead. We could do something similar as we did for slab and mark them deprecated for a few cycles: commit eb07c4f39c3e858a7d0cc4bb15b8a304f83f0497 Author: Vlastimil Babka Date: Tue May 23 09:06:34 2023 +0200 mm/slab: rename CONFIG_SLAB to CONFIG_SLAB_DEPRECATED Then if nobody complains give them the ax.