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 D7BA7C369A1 for ; Wed, 9 Apr 2025 17:59:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 84C2B28009D; Wed, 9 Apr 2025 13:59:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7FCD0280058; Wed, 9 Apr 2025 13:59:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6C33C28009D; Wed, 9 Apr 2025 13:59:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 4E03B280058 for ; Wed, 9 Apr 2025 13:59:57 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 30821160AE6 for ; Wed, 9 Apr 2025 17:59:58 +0000 (UTC) X-FDA: 83315268876.06.6EE9F67 Received: from server4.hayhost.am (server4.hayhost.am [2.56.206.6]) by imf15.hostedemail.com (Postfix) with ESMTP id C33E4A0006 for ; Wed, 9 Apr 2025 17:59:54 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=beldev.am header.s=default header.b=WfudGgJF; dmarc=pass (policy=none) header.from=beldev.am; spf=pass (imf15.hostedemail.com: domain of igor.b@beldev.am designates 2.56.206.6 as permitted sender) smtp.mailfrom=igor.b@beldev.am ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744221596; a=rsa-sha256; cv=none; b=aNUgXU9piuexEloqVoQZpCfI8aoMo87Lr8Iqklrhk0ZuPld2d5Bybj+pIJBcBfXK+ZOo+a HQwfjiWi447bchUwoGQJOc4U4ebGQ+qJ3d3q7rLruHQi5fAGnm4r2o4H2SehjZkZk2SP1y n+KSpLu1fw0OYjoJnPFYYv9s9pDaKwk= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=beldev.am header.s=default header.b=WfudGgJF; dmarc=pass (policy=none) header.from=beldev.am; spf=pass (imf15.hostedemail.com: domain of igor.b@beldev.am designates 2.56.206.6 as permitted sender) smtp.mailfrom=igor.b@beldev.am ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744221596; 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=iIGQFu4G3YqScRtn1MdkImVOLsmCd0SCKYsM1/9sow4=; b=xocepQbvi+fhDCIu2DaxZrZKZC4pRpGCvPpXC3fxdv4FzxX7I2Op+Dey3ZrOaG+2Dy6ddZ nZovvLenC8h/ps2r1cVKNxmx3Fazk3nwuZEqffqTxwpWnpdBP0Qvoy3FDCY7A0eymd1ivh iS17tHShHMSycpTTCsD3+Q8bmhFv3Pw= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=beldev.am; s=default; h=Content-Transfer-Encoding:Content-Type:Message-ID:References: In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=iIGQFu4G3YqScRtn1MdkImVOLsmCd0SCKYsM1/9sow4=; b=WfudGgJFc8NHhnZPweTnChCxw1 ThmJub96UFa/mtraG2OhweC3Z/gQa9zM1l1CJsMqFfxuJsZhyr4+EQDYqsdzQzUWEub9MlLmtmV8R csnd3HiaxvxNF81IC4Hoz6/nGZGyazNQ7SeVlAluckRMispp8wD4TCJx6UpTMtGel1gt7WFflNly3 fKTS1jOH4F7A8nW1LAz8wwDND+i3UwN0/Y/y/rKcKHcfzX27xqCrmIOIktVilODERqHmTk6ScCOG4 hkrN5t26vCBC5zFGtFBvd7x7R0x8mLDyCvnuRLu2ULeFeRadB4MUBI6NdIgYA04dvr3drNewxhlxY sukcUCIA==; Received: from [::1] (port=17876 helo=server4.hayhost.am) by server4.hayhost.am with esmtpa (Exim 4.98.1) (envelope-from ) id 1u2ZiT-00000000Ejy-04sK; Wed, 09 Apr 2025 22:00:01 +0400 MIME-Version: 1.0 Date: Wed, 09 Apr 2025 21:59:58 +0400 From: Igor Belousov To: Johannes Weiner Cc: Nhat Pham , vitaly.wool@konsulko.se, linux-mm@kvack.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, Shakeel Butt , Yosry Ahmed Subject: Re: [PATCH v2] mm: add zblock allocator In-Reply-To: <20250408195533.GA99052@cmpxchg.org> References: <1743810988579.7.125720@webmail-backend-production-7b88b644bb-5mmj8> <0dbbbe9d17ed489d4a7dbe12026fc6fd@beldev.am> <3f013184c80e254585b56c5f16b7e778@beldev.am> <20250408195533.GA99052@cmpxchg.org> User-Agent: Roundcube Webmail/1.6.9 Message-ID: <6e1c6b20481c2cb41930d37da4fe8aeb@beldev.am> X-Sender: igor.b@beldev.am Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server4.hayhost.am X-AntiAbuse: Original Domain - kvack.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - beldev.am X-Get-Message-Sender-Via: server4.hayhost.am: authenticated_id: igor.b@beldev.am X-Authenticated-Sender: server4.hayhost.am: igor.b@beldev.am X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: C33E4A0006 X-Stat-Signature: g79g1h7nrmnimisnw18sysrg3dhcszn3 X-Rspam-User: X-HE-Tag: 1744221594-85169 X-HE-Meta: U2FsdGVkX19rezn/2nvnFfytxLcBjWT55h2WvMosX2ucQgthm+go2CfO6TH/q0gYk7HBhHHpyCL4c1+3Ug5xCXr+Mte51A0GQmXAXLMUATd7rnRpnP7SEGX0mUAn79/PHVlliB5pOa7lQuezijH5BeGbihWW2251f2n5SZVfwyDgjAyZPgu5Xy0yZ1/uoQdsUsPtotDTjEI/alzJwFf4N9RJrq2ppaRvvVpgTgeG14eFv9l/XOC8AeGkLeVzPZvEWy3HPf0AA/IwnaoTpRhJMOpT8Exz/BRJH+pGTFZtrJguUI3o4CcWUQvCg6prK5ElmyeUaiFMI915X72gT6jrz9K4Ljt19vW4qePDSRnNHryV3jxSZZc8wYqG8RAixZwpaQVWOK9JTgbwr+x8auXvSus5Xl5XtN82PKEtY8ZLxP39EJ4fRWUDz6OsRl/sPFc4GWiJXrdXSHPWHis6SJempkLQ/DFeshtPikIPVhK5fJxBvkwGW9UqFf1pxLLAi2Sxv+mpwbsc5bly/RytaqWWZDZsd4nbKd8v3lGqvWXqFTaT6c8t2zIm3NIrAZ2BQKIitoqU4XC7zMyi14v+6vh1a6JWhvVjNlW8xOWNy+gfyTXqR3CdYnWfESalbH2VtqTSjNn0uJoeyNYwGEyjlL3vUmxeceU2Lwc4+EY9OAhR8S4Ht3vjM/8psUjI/7IQW7ZQ354TobmZvNAXLxRiNPi8QLk5Zu1zRfUoZhxlRM32kcaizLlN/gGSF2nN9GEcAdkZf5dNyTOftpvB4rgTm2SXC/Y/et8f9bEvLqTEQgHwo1AoiYsEezZzPd5FgSnObEA7fN7I/zB7NK52c+8XeiV6QdozPU+HoQ2I9g7XJGbEKnymdLjSQFWm2/yMcdlZzrVmigUk9vTeiFji3M7hzcJcveYh0ObM9dv2zw3D2uh9PwhjoI4XXigLQCKLDn4eY69/tR4Hux7Fx1grVJng0NF Cu4jVWwd pqAXIatxp7ZdMoPaEi9VMAL7SWTuUszy425B7Fvhzcna9kO7zwdGwQiEhJmBisqQF3MSpzWWRsgVxlvAuoC5sLppl4t00KU6H0zIkUeHnqM9IYFR7EKt7pDmndyTuvOKdaReB7SHk0ZoA9cevL6LYT+YeWyYKmHDuOnJl9DQ10te4FXbtnEnobjXpc78ng/xKZ/SjQFFUylRClyM/VhVegij7VUEo4FDxO/9hklShBUpok8RLO/gmwwuriwe4oWNv2GI7ShWOI0A5u9gCsvmXoMkoB1TAJOIpO7HvxmTV5/ZVp065IwsEURMHR82F+qWnj8pRCXpfk1ocjGgMqn5FFZTqkjiGvdOkf9387g+NcmjM9c+Lc9MJN4JSVKdQTgRQYtOYK+0ab9dAdhXFYNWaXCe1bD3ZwJGND4F7 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: Hi Johannes, >> Sure. zstd/8 cores/make -j32: >> >> zsmalloc: >> real 7m36.413s >> user 38m0.481s >> sys 7m19.108s >> Zswap: 211028 kB >> Zswapped: 925904 kB >> zswpin 397851 >> zswpout 1625707 >> zswpwb 5126 >> >> zblock: >> real 7m55.009s >> user 39m23.147s >> sys 7m44.004s >> Zswap: 253068 kB >> Zswapped: 919956 kB >> zswpin 456843 >> zswpout 2058963 >> zswpwb 3921 > > So zstd results in nearly double the compression ratio, which in turn > cuts total execution time *almost in half*. > > The numbers speak for themselves. Compression efficiency >>> allocator > speed, because compression efficiency ultimately drives the continuous > *rate* at which allocations need to occur. You're trying to optimize a > constant coefficient at the expense of a higher-order one, which is a > losing proposition. Actually there's a slight bug in zblock code for 4K page case which caused storage inefficiency for small (== well compressed) memory blocks. With that one fixed, the results look a lot brighter for zblock: 1. zblock/zstd/8 cores/make -j32 bzImage real 7m28.290s user 37m27.055s sys 7m18.629s Zswap: 221516 kB Zswapped: 904104 kB zswpin 425424 zswpout 2011503 zswpwb 4111 2a. zblock/zstd/16 cores/make -j16 modules real 15m53.119s user 199m45.722s sys 36m21.544s zswpin 26600 zswpout 287021 zswpwb 0 Zswap: 205908 kB Zswapped: 858516 kB 2b. zsmalloc/zstd/16 cores/make -j16 modules real 16m31.052s user 207m3.612s sys 37m49.891s zswpin 27044 zswpout 296763 zswpwb 61 Zswap: 198740 kB Zswapped: 868020 kB So what we see is: * on 4K pages, zblock matches zsmalloc with regard to storage density on longer tests and gives better performance in virtually all scenarios * on 16K pages, zblock is superior to zsmalloc in terms of both performance and storage density. > This is a general NAK from me on any new allocators that cannot match > or outdo zsmalloc storage density in common scenarios. I'm sorry, but > I really don't see any reason to do this. Given the above, I sincerely hope that you reconsider. Thanks, Igor