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 DB163C48BEB for ; Thu, 22 Feb 2024 06:23:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3747C6B006E; Thu, 22 Feb 2024 01:23:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2FE7B6B0071; Thu, 22 Feb 2024 01:23:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 177EC6B0072; Thu, 22 Feb 2024 01:23:58 -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 055AE6B006E for ; Thu, 22 Feb 2024 01:23:58 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 903C6C0C88 for ; Thu, 22 Feb 2024 06:23:57 +0000 (UTC) X-FDA: 81818449314.26.46C5BCE Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) by imf07.hostedemail.com (Postfix) with ESMTP id C317640013 for ; Thu, 22 Feb 2024 06:23:55 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=AmSkamfx; spf=pass (imf07.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.166.50 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708583035; 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=ri4f+uV+Toa3UuYT6CTdh8+5f7xMDn6MuuNtTjFrq2c=; b=JZdiLyp/WlvqeBwni8kWjUsKmt28hRWADxjtC6QMCXSZqLxOYGpGG1rE2WidlLU37Dz9VN ns+bnsE9ppGfZI9LDLMrbASCAtUAF62umxHpvU/GIA9Hfib9PO84E91wDcroo+tRs517jS +TKi0dIBXRTQpq130ZHwPbEcz4y/ybM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708583035; a=rsa-sha256; cv=none; b=4liFT6fKq0m/EorG+1JzS3GyJ7ru3eb5S+a5utt6BoUiEso243XPpRsLT5Dx1TBDfIS7/m HNoPma5PXQc1gcft4O1uV0cRrFq9+VwXIoANU7kBBcC6Fqq06D9PZBkL/BykPmZAeZmbRn rV74utIWjBU/rAA7EFQ+reAlUYs8bQs= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=AmSkamfx; spf=pass (imf07.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.166.50 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-io1-f50.google.com with SMTP id ca18e2360f4ac-7c48e13e0d7so326674439f.1 for ; Wed, 21 Feb 2024 22:23:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708583035; x=1709187835; 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=ri4f+uV+Toa3UuYT6CTdh8+5f7xMDn6MuuNtTjFrq2c=; b=AmSkamfxpuIK2BEB9FFM7Lm2x+Lm2dUBuYLMMjcGpnOH77ByALyKFV01h/LsIZkjq0 pozOWMdizsSdeMCqR0SemhH28dzjMTICP3jE604cKeuGRpjGnv3zbY/4ORdNqEzYMPDC Cv3CeGMuQa6mL1DWrJiBTOhllG7bll+MFAanYgZUEXQ0JO2f2gMxjG/yS/wxCG+NrimO 6cZ+KrhRHV/IwZl6TcMMVE291prrXY0fux4KDmtjkU3/2FtRMiUVUM5qG6pHuLc2XFZa gEGTx/1FQ+oAqggOrckk0aVECBQt09U4Ckm0dhxYc2B7gSlLdkpBf0psAQKKeuhwi+17 mPQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708583035; x=1709187835; 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=ri4f+uV+Toa3UuYT6CTdh8+5f7xMDn6MuuNtTjFrq2c=; b=Z+tDBYF6pII6gtr+ld6Zgh1pcnVbx5M5fnunwIOIpGCYTIXgbH/gmKRSvwIdBE+pkg Ug5XZlMIkcci0uccCr8jvkR1dYGP6m1a6/LzfMPIrbVXEhqp7mZhd8ukucR9WO2IY9mO 1JaBdrN3a1Uy2NbHYKfDpU7sdH8M4wfAqtnV/W4BusVeIhWcv/vtf6JD2ze/TUpVDu5i T8hdW2gC5BQE5JXRVZMsa9Esl0JE/Z2f8YnJ2ChBYy1wcQ/p0pK72NZwsRGvIwIMcK8h eudoiiLEDN/WhgXdy5v82BPU8U5+WUik2MAzvM/r7Z/oZeP+9lrrvl9IonO2lo3NJ81d SwBQ== X-Forwarded-Encrypted: i=1; AJvYcCUBtMs10o6HeDWVxm9ISLI6pf0O4lPB1IuM0d9qM1MHY8ka7JYThGC0/f74SivfahL/W1Mdwi5hVZCGkaAW8NoB2kY= X-Gm-Message-State: AOJu0YzyHrPO4/1wgR5pjPvRfzwUuEbz995KGd8P/23mNkZJm/K0SSMU vXGWtFBrY2rPcx9xrSvsBDVaVZNfziB23RdFap277Qr21OuX6vSZgC9Ncf8/UEsxstcohneUQdA kdLK0LBQ/xySnzIhTkw169+UCrg8= X-Google-Smtp-Source: AGHT+IFx6A+ZYKinukfXkiKrDWkPWs1ONeI0WZZ/VbxPqFeMwyQsl8NB1X68JpTnSemRLKt66Lql+o3oiL3xObhp2PI= X-Received: by 2002:a05:6602:e46:b0:7c7:43f5:26a0 with SMTP id gq6-20020a0566020e4600b007c743f526a0mr13018369iob.1.1708583034853; Wed, 21 Feb 2024 22:23:54 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Nhat Pham Date: Thu, 22 Feb 2024 13:23:43 +0700 Message-ID: Subject: Re: [RFC] Analyzing zpool allocators / Removing zbud and z3fold To: Yosry Ahmed Cc: Andrew Morton , Vitaly Wool , Miaohe Lin , Johannes Weiner , Linux-MM , Linux Kernel Mailing List , Christoph Hellwig , Sergey Senozhatsky , Minchan Kim , Chris Down , Seth Jennings , Dan Streetman , Chris Li Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: C317640013 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 8azh6m8xoo1eak83h8j5b3zm64psb3o3 X-HE-Tag: 1708583035-658320 X-HE-Meta: U2FsdGVkX1/mW6c++r++8L+3LCfr7/1TbI1LrtqgG+524Fqn7/ragWZQGM1OvEx2hcbxDzj9VS/Nm8S2J7A3kmKlgUO+Ms14b2pYXCuPgQecD28ESBlYzGsPQf0QXvFgw7n2ejtUEXjTSctK78i0eooXiiqoXahrISGzPf1iYJ/mCVVNpzWw26Cqlr4NnnALdGbRgeQj4kpfrr1EphKiiKzLMWuTYbbjkp5niDHLsIhkOq2gGx8wBqGznBxvaCwDvDBOWicMaUDg4hy8ef0l+Gck0kFKn8oZ0zm8a9gBiOZ1TMDX5QGikYUI0o8PiYH81vkXA4avfwitL8USgWj3VSd8qgnr9j5zridGYJH36z7i2mihwHURWGGTHPWcCKJy6yDSmlF0IDE/iLIaBJIusFtNMGEuoQsYe46FRXjH6tMEFYPPphRiLlLNBT8ipL9dPwaqZTpjWKshx4Q20Lnp/pK8PGIfFZANRh97WD0crotz8yncozSn/w4Z4jcOah3gEvmKKZkylktINfHXV1nQWcjGhzQY3U1r6Km/akGqxMUe+YvmxsrwgdN5//40AlNdCa/jj+rO/APCFS9nZOCsGe+npOgb9OaxxPR70tJkubTngCRwM0RVV94cl/LAsvWqi4bMmhZ1pXr7tu1ybrzkonx+zLXzjjkPxE0r8c1soHM0YDsy8JeG8txTJx/5ROCjbPhNJoqDYaToyOuVKQvywftAWcmZTbWDrSsAb0TsLy1yA9EncgRDiQuhOsSeHyYaRSC4E2QvrxqLxHoFp7zzugenZTKCeGKn2BiIrF78KuGNyf9fpKPeEpJGnhfqfUIEp/1sK2m3PEYvx0y/qQy6x/WPnmvEpqSNZKyEDqv2uTU2WGG+ADtKcexA3XpeE7CSVbEWEJj+D9/Ik4FN6Z/9kF0s+mo/iFXJ2/G7ObQh2eDoa6hltL0Vqr9GYoBNzgsiPeQSClzm9YVLcdJei12 ZnbZGZnd +loqN8QK0jeqgIKTfSQXZnKMD5jMroVpvVEqdwWtcuK08m5Wsraa1wP9i51eGzTYdfXhoF01iWKoOczLrNlnJclKQmrn9Z7am6N383gFcqsvO7M5KpXB9g+x0C9y2cXQ0dutwf5F0NjodZDofS7A7gJVy9nhMWzNGg8n8PP+bHiGiZq5jDMJPFLOfeAnurxcS/uKoti2F+uY0g/NZBFoh7IVfjxGyhLRG2E37iJsqeLovb78PlBAblBNvzQFWHPmOoYQct8bh0OanunxojFHe7BIm8jyb5uE9e4lA X-Bogosity: Ham, tests=bogofilter, spamicity=0.000054, 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 Fri, Feb 9, 2024 at 10:27=E2=80=AFAM Yosry Ahmed = wrote: > > I did not perform any sophisticated analysis on these histograms, but > eyeballing them makes it clear that all allocators have somewhat > similar latencies. zbud is slightly better than zsmalloc, and z3fold > is slightly worse than zsmalloc. This corresponds naturally to the > build times in (a). > > (c) Maximum size of the zswap pool > > *** zsmalloc *** > 1,137,659,904 bytes =3D ~1.13G > > *** zbud *** > 1,535,741,952 bytes =3D ~1.5G > > *** z3fold *** > 1,151,303,680 bytes =3D ~1.15G > > zbud consumes ~32.7% more memory, and z3fold consumes ~1.8% more > memory. This makes sense because zbud only stores a maximum of two > compressed pages on each order-0 page, regardless of the compression > ratio, so it is bound to consume more memory. > > -------------------------------- -----------------------------= --- > > According to those results, it seems like zsmalloc is superior to > z3fold in both efficiency and latency. Zbud has a small latency > advantage, but that comes with a huge cost in terms of memory > consumption. Moreover, most known users of zswap are currently using > zsmalloc. Perhaps some folks are using zbud because it was the default > allocator up until recently. The only known disadvantage of zsmalloc > is the dependency on MMU. > > Based on that, I think it doesn't make sense to keep all 3 allocators > going forward. I believe we should start with removing either zbud or > z3fold, leaving only one allocator supporting MMU. Once zsmalloc > supports !MMU (if possible), we can keep zsmalloc as the only > allocator. > > Thoughts and feedback are highly appreciated. I tried to CC all the > interested folks, but others feel free to chime in. I already voiced my opinion on the other thread, but to reiterate, my vote is towards deprecating/removing z3fold :) Unless someone can present a convincing argument/use case/workload, where z3fold outshines both zbud and zsmalloc, or at least is another point on the Pareto front of (latency x memory saving).