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 439C2C369C5 for ; Wed, 16 Apr 2025 20:10:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9F9176B02BF; Wed, 16 Apr 2025 16:10:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9A75E6B02C0; Wed, 16 Apr 2025 16:10:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8701C6B02C2; Wed, 16 Apr 2025 16:10:32 -0400 (EDT) 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 68FB56B02BF for ; Wed, 16 Apr 2025 16:10:32 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 56308C0D45 for ; Wed, 16 Apr 2025 20:10:29 +0000 (UTC) X-FDA: 83340999378.19.DCD4F65 Received: from mailrelay4-3.pub.mailoutpod3-cph3.one.com (mailrelay4-3.pub.mailoutpod3-cph3.one.com [46.30.212.3]) by imf13.hostedemail.com (Postfix) with ESMTP id EE1C920008 for ; Wed, 16 Apr 2025 20:10:26 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=konsulko.se header.s=rsa1 header.b=44mcSPmj; dkim=pass header.d=konsulko.se header.s=ed1 header.b=4dDNSndc; dmarc=none; spf=none (imf13.hostedemail.com: domain of vitaly.wool@konsulko.se has no SPF policy when checking 46.30.212.3) smtp.mailfrom=vitaly.wool@konsulko.se ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744834227; a=rsa-sha256; cv=none; b=v3aJ9P4aEXQzrcnUixM1Yb3hbtSdWpsabFOtJotvvdVvR5OatzIX8KGXNXqqHcBnI0R+qS xnJsauhLdAIapErqz95HxnkgoDSDUi5SkwwkYlhs/CLWHXS7yw6vA0eXFymMwZNhJ0Vkfb eiCQk51DuuPIjibX2VYh2SiYfyVNrNU= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=konsulko.se header.s=rsa1 header.b=44mcSPmj; dkim=pass header.d=konsulko.se header.s=ed1 header.b=4dDNSndc; dmarc=none; spf=none (imf13.hostedemail.com: domain of vitaly.wool@konsulko.se has no SPF policy when checking 46.30.212.3) smtp.mailfrom=vitaly.wool@konsulko.se ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744834227; h=from:from:sender:reply-to: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: in-reply-to:in-reply-to:references:dkim-signature; bh=aSNO75mn1cr3wOJIU3+8s5gzhZYlmPJQEGWJ6eyXnBI=; b=BmnvWz3gDRkUUvPJBMx7yke5BtNfSVosbdE/vHtHsR3tMKbvvwPBP05XEWvqSa34scE5iv NxQ2Of6Pt30sjux+15vfEhCeclmNZ1lnJtflYPJYbFmyuAzkXxWHkMJEZ7GGRUWEsFHkvd lMVDCmr66sMBXP56cZonNe8j/u06lMk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1744834224; x=1745439024; d=konsulko.se; s=rsa1; h=content-type:subject:reply-to:cc:from:to:message-id:mime-version:date: in-reply-to:from; bh=aSNO75mn1cr3wOJIU3+8s5gzhZYlmPJQEGWJ6eyXnBI=; b=44mcSPmjEUdPd4hehtDDvh9Fz2aGtg3WrwiHetfxhfOdXu+7fjTXoIzFOJ06y2duRksZ5q2jHb/pK h27wzDhm8tcPEYtX4NhG3SH9icrQ4uui1gb4nAQe6ZXLCaOHiVa5/rwNcVTh7cEn3Xo79LW/C/GvDZ 2gJ1rp6NVH4cZ8MUcYgloeFy41eGnhBTNRj12l+Io6ml1Sq6gORyCHAvNduTeYciDTsKYKsRPeLXrM mERKePz3jAJf+TnO3jSFsDoAxInlUWHaQHwj0eYtSuwlbZzXkewp0uChjyPo6prsTuLBvN274752I/ ni+5K+CwjPdbOsESAjhuVgHS0M5lVBA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1744834224; x=1745439024; d=konsulko.se; s=ed1; h=content-type:subject:reply-to:cc:from:to:message-id:mime-version:date: in-reply-to:from; bh=aSNO75mn1cr3wOJIU3+8s5gzhZYlmPJQEGWJ6eyXnBI=; b=4dDNSndc+AzLQ54TQD1XJ5kXqOhd7+22HKPil4lVXOGK2OIyY/7q6S2emWyN0VriQWZJ1b1bB+UcI 6we4pbwAw== X-HalOne-ID: d4c5a168-1afe-11f0-a292-29b2d794c87d Received: from onecom-webmail-backend-production-58ff969799-9sgvc (service.pub.live1-k8s-cph3.one.com [46.30.212.67]) by mailrelay4.pub.mailoutpod3-cph3.one.com (Halon) with ESMTPSA id d4c5a168-1afe-11f0-a292-29b2d794c87d; Wed, 16 Apr 2025 20:10:24 +0000 (UTC) X-Originating-IP: 194.195.91.56 User-Agent: One.com webmail 48.0.17 In-Reply-To: <20250416120912.GC741145@cmpxchg.org> Date: Wed, 16 Apr 2025 22:10:23 +0200 MIME-Version: 1.0 Message-ID: <1744834223790.7.2308@webmail-backend-production-58ff969799-kbd7f> To: "Johannes Weiner" From: "Vitaly" Cc: , , , "Nhat Pham" , "Shakeel Butt" , "Igor Belousov" Reply-To: Subject: Re: [PATCH v4] mm: add zblock allocator Content-Type: multipart/alternative; boundary="----------2306-1744834223790-1" X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: EE1C920008 X-Stat-Signature: wzdharox8qgk19doo5n9at7rkboru4xb X-HE-Tag: 1744834226-227166 X-HE-Meta: U2FsdGVkX18I6pY+ytWp7QP27xG7/pPzwd0945mxYxDo5bzkFw78R1Sjl+PuPE90MzRViB6hAMVVMHaGMVbKY+qdhBcNhThtaMvL9EfY+y6OE2wA8n3GUSYhUy9cH0K32jDsM5veHkvwTFZ5fRATfAldXIZDmaksvvh5PNxuTE4vxSqHiUccILX8twXfElhlJlqQh5/MJ2vUqZaK7Q0WW0MkomzRPgs3hx09t8C0avKRNSPTfkVbJ21mqqgVJqmorEIzPnOEL/rNFwStzMuR5WuWnfsH1Sj6AKvfqJXsP9EHgJIO6FKs6ZKXOUNG8l7O5jZVO98v6HnvsqQyBpjBuZCT4J4qg/tZ0lxPU0MvNNKWfj1ffxRDpTtO+tnM+qa11wTkVWOyJtDSmEF/OoP3p+4Dv7GOZrAviWNlxnZ7YWHgsdciQZe/GkJDALDGAGM7Hzho0rlZu5Bdx3earTgw4RAdvEXPWebCi/p3iJG7BI42GVFXNs0ER/SiyH6gYbFHEyTraqhEYJQJq9+SpPgtP/Vk2oGjBrQAb2t51e1B4KF8m/sJ4ttfMcpek52NMhiA2kU2mlphW/PCv6hPZzxv8dCa9dfk3uBIsHsQwxB16lkq93ZFZ0TagSOPVRPcabtxJ61w0AKqelYlCKDn3PuyFjSzo0W6M8mryQ8QwiTibObjy3stObxhQfs4ls+jjAMNPwsVMN1rpa6k9XU+JgRPLUcFzdqL85BuFLq0dEyoYyqKvfj+n1qVhwiuZEZhHgr6PH1qz5vI04uVMwiKewOXQvbzF2wVVKuQxJaFKAnG+wUPS/dNKGkfYClPsBzwdKwGuQhogQ1TvoJX1pEYOX7FaYm4j977fJc8DqraFLgb/6OiRvMhNiqgDeKpAzziW5AFQGf8EC2Q6DH8ffj00jR36B3QK7MRciPVm7GI+Luuh1pl2dK5qHF0yxQI4S1nssmSf+zwHWkwaToRJxWfMxD jUiDo6sT N6ZulfkIjzlx3pnw6GDdDxbWjU6jGmqU0KVejoGCELvLGK/wSYJKR7QB3WZrDW3vsRVq10KzhtRxGGiXcwbeNoXP7yLtexNG8PEXL0+1Uy0MUTMBQ0d/QAgTli6BlPF4WKTX48pXW/GaQbi229MjtxKQjGxnJaIVadlkcdYz8HeU/8VZCvForgDKP26DUmNEoOZbDCmq1eFgY6yY0ClnLX/fK2SZXSKDP6T62KVyVf7/2qCMGlzDFfc5MkdP6cCwqjjlA5WG41rFZajNBoIxJyNVOsD8MUj6OpeJRdLW15+dln7bogl6SDwh9BcoOfIkoXYijSTAbFf4xuaom1G3FH5R6AA3kVmYcNQVerdE+0wXaYqENao4kdBNvHkAGL1yu2E3Q1kLjC8+7EEamWiOpJTHKe9Lms1XYLsfCEd1Tm+0heHQ7ThDbwhsmd2TXR+dXp+OUNqyAFHRq4YN2sTv5/4LUfoaMRD6QHj+ZUPjVz3POHagGtGT1q7hVWGF37caya905riLG2OwAogWYCNyXacw8DG58mc19JRh2EeU3OY7tkWntLxT9KpiK4Vr/bOGFCUrDqoprak72BxbLgpcDYWc3EQ8pwsAolVWH 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: This is a multipart message in MIME format. ------------2306-1744834223790-1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 On Wednesday, April 16, 2025 at 2:09:12 pm +02:00, Johannes Weiner wrote: >> zblock is also in most cases superior to zsmalloc with regard to >> average performance and worst execution times, thus allowing for better >> response time and real-time characteristics of the whole system. >> Is there a reason not to use this allocation scheme in zsmalloc then? Introducing such a scheme in zsmalloc is theoretically possible but it appe= ars to be more complicated than implementing it from scratch, which is exac= tly what was done. > I'm curious what others think, but I'm still not convinced a second > allocator makes sense. It's maintenance overhead, a permanent struggle > to match feature parity, and it fragments development and testing base. > Not long ago several slab allocators were removed for those > reasons. Likewise, we just deleted zbud and z3fold because they didn't > get any attention and bitrotted, but not before years of inflicting > pain through the zpool interface, users accidentally making very > suboptimal choices, reporting the same bugs over and over again etc. I'm not sure what pain you are talking about. There were reasons why z3fold= and zbud existed. z3fold and zbud were the ones that supported page reclai= m, zsmalloc wasn't quite usable with zswap until recently. When we did z3fo= ld it was outperforming zsmalloc. With that said, I didn't object to removing z3fold because I did understand= that it made no sense to keep it at that point. > I also don't buy the fragmentation argument. Even if you are better at > packing during allocation time (although, citation needed), the > workload can unmap swap pages such that they leave partial blocks > behind indefinitely if you don't have block compaction. We published Zswap/Zswapped values for zblock/zsmalloc after stress loads a= nd those were on par, basically. > Then there is the migration support, which you said is planned, but > which would presumably require the same indirection between handle and > the backing pages that zsmalloc has. How much will this eat into the > performance advantage? I don't think that will be necessary. We're working on supporting GFP_MOVAB= LE and minimising high order allocations > I'd much rather you'd focus on making zsmalloc better. Improve the > packing scheme, make expensive features optional/configurable etc. > That would be easier on developers and users alike. zblock's source code is almost 5x smaller in size than zsmalloc's and yet z= block works better in many cases with just a few bottlenecks. Why would you= mind that we'd focus on making zblock better instead and possibly retire z= smalloc when that mission is accomplished, just like we retired z3fold a wh= ile ago? Best regards, Vitaly ------------2306-1744834223790-1 Content-Type: multipart/related; boundary="----------2306-1744834223790-2" ------------2306-1744834223790-2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

On Wednesday, April 16, 2025 at 2:09:12 pm +02:00, Joha= nnes Weiner <hannes@cmpxchg.org> wrote:

>> = zblock is also in most cases superior to zsmalloc with regard to
<= div>>> average performance and worst execution times, thus allowing for bet= ter
>> response time and real-time characteristics of the who= le system.
>=C2=A0
> Is there a reason not to use t= his allocation scheme in zsmalloc then?

Introd= ucing such a scheme in zsmalloc is theoretically possible but it appears to= be more complicated than implementing it from scratch, which is exactly wh= at was done.

> I'm curious what others think, = but I'm still not convinced a second
> allocator makes sense.= It's maintenance overhead, a permanent struggle
> to match f= eature parity, and it fragments development and testing base.

> Not long ago several slab allocators were removed for tho= se
> reasons. Likewise, we just deleted zbud and z3fold becau= se they didn't
> get any attention and bitrotted, but not bef= ore years of inflicting
> pain through the zpool interface, u= sers accidentally making very
> suboptimal choices, reporting= the same bugs over and over again etc.

I'm no= t sure what pain you are talking about. There were reasons why z3fold and z= bud existed. z3fold and zbud were the ones that supported page reclaim, zsm= alloc wasn't quite usable with zswap until recently.=C2=A0=C2=A0When we did z3fold it was outperforming= zsmalloc.=C2=A0

With that said, I didn't object to removing z3fold= because I did understand that it made no sense to keep it at that point.

> I also don't buy the fragmentation arg= ument. Even if you are better at
> packing during allocation = time (although, citation needed), the
> workload can unmap sw= ap pages such that they leave partial blocks
> behind indefin= itely if you don't have block compaction.

We p= ublished Zswap/Zswapped values for zblock/zsmalloc after stress loads and t= hose were on par, basically.

> Then there is t= he migration support, which you said is planned, but
> which = would presumably require the same indirection between handle and
<= div>> the backing pages that zsmalloc has. How much will this eat into the<= br>
> performance advantage?

I don't= think that will be necessary. We're working on supporting GFP_MOVABLE and = minimising high order allocations=C2=A0

> I'd much= rather you'd focus on making zsmalloc better. Improve the
> = packing scheme, make expensive features optional/configurable etc.
> That would be easier on developers and users alike.
<= br>
zblock's source code is almost 5x smaller in size than zsmall= oc's and yet zblock works better in many cases with just a few bottlenecks.= Why would you mind that we'd focus on making zblock better instead and pos= sibly retire zsmalloc when that mission is accomplished, just like we retir= ed z3fold a while ago?

Best regards,
=
Vitaly
------------2306-1744834223790-2-- ------------2306-1744834223790-1--