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 0CD72C369CB for ; Wed, 23 Apr 2025 19:53:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2505B6B0007; Wed, 23 Apr 2025 15:53:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 201646B000A; Wed, 23 Apr 2025 15:53:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0C9626B000C; Wed, 23 Apr 2025 15:53:55 -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 E28C36B0007 for ; Wed, 23 Apr 2025 15:53:54 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id CEB75C1E9B for ; Wed, 23 Apr 2025 19:53:54 +0000 (UTC) X-FDA: 83366359188.05.C4DBF5B Received: from mailrelay2-3.pub.mailoutpod2-cph3.one.com (mailrelay2-3.pub.mailoutpod2-cph3.one.com [46.30.212.33]) by imf25.hostedemail.com (Postfix) with ESMTP id 48ABFA000D for ; Wed, 23 Apr 2025 19:53:52 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=konsulko.se header.s=rsa1 header.b=FzYSIMOH; dkim=pass header.d=konsulko.se header.s=ed1 header.b=ouajgcZY; spf=none (imf25.hostedemail.com: domain of vitaly.wool@konsulko.se has no SPF policy when checking 46.30.212.33) smtp.mailfrom=vitaly.wool@konsulko.se; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745438033; 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=qA+d6OUZ9bNJv97jT/8eGXPf4gfJm5aPw309Dk0gVRU=; b=pn/RsjbaPUeJMdd9mGMPZnpYf5s36Bp8IlbqFyaJh5MVpd+DDPM9wiUo922bagbYcDti+P WclUeThf2Bi2dWXYqow4bzccHDMCn2lAT9peqUEjBiW7lk18NYp3x2LlMwZ8lU5UJH6Oso KjE9vfjDnSSaQz2V0VFS2jMbKH0G6CE= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=konsulko.se header.s=rsa1 header.b=FzYSIMOH; dkim=pass header.d=konsulko.se header.s=ed1 header.b=ouajgcZY; spf=none (imf25.hostedemail.com: domain of vitaly.wool@konsulko.se has no SPF policy when checking 46.30.212.33) smtp.mailfrom=vitaly.wool@konsulko.se; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745438033; a=rsa-sha256; cv=none; b=XLP7CVG6BLLSKtAlSZkDmK4HHejOKr9+hnrV3F7AsVJDVxK06f/tPEgR3B/ZUQdaUTgYGC MCaYVhmGgIqI/D23byPu7ghmLamRHrCXClZl8Q2UL92LXi9uKjnhuIgP/orRLZa7iccXX/ ID57j0QgUbzXluQDs3Gj22QCiUbqbFg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1745438029; x=1746042829; d=konsulko.se; s=rsa1; h=content-transfer-encoding:content-type:in-reply-to:from:references:cc:to: subject:mime-version:date:message-id:from; bh=qA+d6OUZ9bNJv97jT/8eGXPf4gfJm5aPw309Dk0gVRU=; b=FzYSIMOHEJIBwbrlQ+/LIkdNQgag36MUq1WDzNkxO/TT1CtGqNziVPJ39ef5InR3su57uidWCR9TB bxRMqCus+Ts7ij7U6jv6lbRI3aVNVWHunkm4yr0NrmywsqAVH8E0yk59Ccho4FQJT0z3cVJ5IlaOG+ wweSSK9ORlLA1CT1KvgXa4teJQ839iFjIhKa46hPbOLiatSgVwt9HI+tFXkbkivPtsl4oa8AP0FZnb wRyPtOOmjCZvELGQvdjr4UV8d+U7ue/AAze+afM/5yWxeqVns70G6W7E+iTWIoACokdcmII6YP194+ YiH4x6K52zaCo8eraz2924qy6iw34Gw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1745438029; x=1746042829; d=konsulko.se; s=ed1; h=content-transfer-encoding:content-type:in-reply-to:from:references:cc:to: subject:mime-version:date:message-id:from; bh=qA+d6OUZ9bNJv97jT/8eGXPf4gfJm5aPw309Dk0gVRU=; b=ouajgcZYWzmj9qoZbAAvwpJk7klAZdzdemlpG/tu6s5AvydF9I+k9bsZ5MFYQGysU+s99MAfxwZFU 3fRYJjZDg== X-HalOne-ID: abfa3abc-207c-11f0-bd4e-91f375301d21 Received: from [192.168.10.245] (host-90-233-218-222.mobileonline.telia.com [90.233.218.222]) by mailrelay2.pub.mailoutpod2-cph3.one.com (Halon) with ESMTPSA id abfa3abc-207c-11f0-bd4e-91f375301d21; Wed, 23 Apr 2025 19:53:48 +0000 (UTC) Message-ID: Date: Wed, 23 Apr 2025 21:53:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4] mm: add zblock allocator To: Yosry Ahmed Cc: linux-mm@kvack.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, Nhat Pham , Shakeel Butt , Johannes Weiner , Igor Belousov , Minchan Kim , Sergey Senozhatsky References: <20250412154207.2152667-1-vitaly.wool@konsulko.se> Content-Language: en-US From: Vitaly Wool In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 48ABFA000D X-Stat-Signature: y5bx3uurox6nfx11j9uku6syxsnx6m96 X-HE-Tag: 1745438032-815061 X-HE-Meta: U2FsdGVkX194dbS9lVEf6b0P5Uiizvze+L5C8Y5zIxudwOxfW5jhd0r7/TJOFnNK36qrLGySH2h9dpfBmleE1VunFba2I8mBoGvQBLxhf4W0pBTk0feX6GFSwmaPP1GM7qbE9GRjQ63bOSDNl9tiIGQob1dlkFetfNdW3x7TCNCbsJ+f24Z4ngZRUORfYB6aQ21EERN/e69kjpHdF+2tgea8gg2PlC5DujvTM18HGBcEHpapgYsUFmRMDawIRBzi0s3Anee7IEk0LEuZy0WHyQqdNqbDDQP1phYHLtvScl0UDxYjVNZjiEJRRoZv+ha78zELDmpANvVcDiTH/U0ntRxaCU36OwpbPwd5Zx5YW9FZ5VcygGpA3+/1V9spWfOYQSlpOK0yK0dDSGOL2GlL3ToNC15suRZw1z/PNrtBagtqS0BlO1NLFChvZN2JAcbSsY0CeE1Q01nHpq9+kKoXwDBcirlk/aDk1jJvzrwKoYm6RzpSb9KS35VQ1mVZN1wYrc4sy7VzldC8BEFFcVl0xEk2Raz8kKbCbxNo5kLdyE7vSy0P5hMSdphtvCJsTPY7fjsnQVpRYinkt1Q44cAZdvqGcnzSff0UjbqjeCfAtP4VipPJLMfmhovAH5i0XuYbMEE+D++wHhn4PYM58OL4nZmPal+iZcpaxqFZNmdVsyXn/x1VdKKuYGCM7vtlOOS2TM44B2mxgPpJY4RNFP7FgRlUR+Mk3ry5/eE+lSYOfPLdKJHCpg1ApqkTWUhPvDESJl+DjJ9jTF2MFRekoA3vMfAZP95WA3A+Xrz9N+dx0y8yyhimOeaa3sd17/TLZEHiaI7umnX8yEFw7TRtq8GjH2a6YYIfTlou+4xfWGiZyPZYSc4GcMEnHxTfLKwNCNDRTxwC0lnPRmDqwTdZkxwHaW6+9UHCiLYiHnSHWxi8hLFZpWBZUMcERelsDY6k7qFv4YkXfuIsOeHM17Kl9Tg F5pXuEda Yy1OjrI39/N421GiI+otDIUC5EY8CkoWxXw1jj4lzzVsbiFpH1A7ShtAkk9XEg9RC7fEtVSzNUSuS7dJaaS3DzcjlREGtAb3r/Ge3JhXQWlshBVSBEWNmsPBChpSKfV+w+OqXXAdLecloI+FsDF3v/OnG5aQF21K7oLElqMsp7em7KbE2H59o+f6nn3LwyNtyS5q+sR7yDlXcmAZS4dcfuBVDhhSHK9RXHu1AOe8HqLQ2IXs= 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 4/22/25 12:46, Yosry Ahmed wrote: > I didn't look too closely but I generally agree that we should improve > zsmalloc where possible rather than add a new allocator. We are trying > not to repeat the zbud/z3fold or slub/slob stories here. Zsmalloc is > getting a lot of mileage from both zswap and zram, and is more-or-less > battle-tested. Let's work toward building upon that instead of starting > over. The thing here is, zblock is using a very different approach to small object allocation. The idea is: we have an array of descriptors which correspond to multi-page blocks divided in chunks of equal size (block_size[i]). For each object of size x we find the descriptor n such as: block_size[n-1] < n < block_size[n] and then we store that object in an empty slot in one of the blocks. Thus, the density is high, the search is fast (rbtree based) and there are no objects spanning over 2 pages, so no extra memcpy involved. And with the latest zblock, we see that it has a clear advantage in performance over zsmalloc, retaining roughly the same allocation density for 4K pages and scoring better on 16K pages. E. g. on a kernel compilation: * zsmalloc/zstd/make -j32 bzImage real 8m0.594s user 39m37.783s sys 8m24.262s Zswap: 200600 kB <-- after build completion Zswapped: 854072 kB <-- after build completion zswpin 309774 zswpout 1538332 * zblock/zstd/make -j32 bzImage real 7m35.546s user 38m03.475s sys 7m47.407s Zswap: 250940 kB <-- after build completion Zswapped: 870660 kB <-- after build completion zswpin 248606 zswpout 1277319 So what we see here is that zblock is definitely faster and at least not worse with regard to allocation density under heavy load. It has slightly worse _idle_ allocation density but since it will quickly catch up under load it is not really important. What is important is that its characteristics don't deteriorate over time. Overall, zblock is simple and efficient and there is /raison d'etre/ for it. Now, it is indeed possible to partially rework zsmalloc using zblock's algorithm but this will be a rather substantial change, equal or bigger in effort to implementing the approach described above from scratch (and this is what we did), and with such drastic changes most of the testing that has been done with zsmalloc would be invalidated, and we'll be out in the wild anyway. So even though I see your point, I don't think it applies in this particular case. ~Vitaly