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 B8D11C4321E for ; Tue, 29 Nov 2022 13:44:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3598D6B0072; Tue, 29 Nov 2022 08:44:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 30A506B0078; Tue, 29 Nov 2022 08:44:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1D2906B007D; Tue, 29 Nov 2022 08:44:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 0E3D26B0072 for ; Tue, 29 Nov 2022 08:44:05 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 6D2FA120F12 for ; Tue, 29 Nov 2022 07:48:42 +0000 (UTC) X-FDA: 80185702884.21.3515BC9 Received: from mail-pg1-f177.google.com (mail-pg1-f177.google.com [209.85.215.177]) by imf11.hostedemail.com (Postfix) with ESMTP id B98BB4000A for ; Tue, 29 Nov 2022 07:48:41 +0000 (UTC) Received: by mail-pg1-f177.google.com with SMTP id 136so12289495pga.1 for ; Mon, 28 Nov 2022 23:48:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=PWU1tUSr5RkkApX8UFtNyIIV+SLqQ7dDSXcXlbOVzkg=; b=nPYKrvNbdhkaXrtvGsjoA7mOOqa00dW25/ipL3aQbI+Xp31sUY8PW2rhJvoN6vpdKL RUauI1G6k7Oxjk8WaE0LYpK61859YE3BAbNlFX/4aUnn371u2UeZHXffqnxn3xhY8EN4 RhQnWjfdpjdONthZA6EoRwe3n9l5wWrz16ejI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=PWU1tUSr5RkkApX8UFtNyIIV+SLqQ7dDSXcXlbOVzkg=; b=eKKemDijXdCDgV0Ai/Yzq7ls3ARJ6xNDjzyE7O3GFCRw+Ws7GOvBMPJ7s1fU/1N6e9 I+sc4CIijQi7FLXGAex47q6vYKb0J5SH3Wf40PdZa2RDTYoM7NikDUzCzxbktz3eUWO4 OlE4KSi9mlnWi2xowWhSgWbEZUPmpMWgeK3qePqbaKttIWXbCwBc4tWHBi0HvaBtAlMF gw9DWLvXHS5maUhiadWcBGgNKhHRlkFtsn1OPjgIb/gPJn8tfrSOl7lQVNf7aRlu7GlB fZYvwsRn59w3rhqwB5tgJ+guOIM5EqCdA5B/Do4Hqjbbr8V00GkmDHeot4C2LGdX49X0 PwXQ== X-Gm-Message-State: ANoB5pkk/7xTApoZfh3jHqCoHCIDuEbnNU3ddjkDuCkiHBSqR+SfHgnj spzLU7KPKqZCeoY2Lraup+cguyR1PteIEUroe96ZiA== X-Google-Smtp-Source: AA0mqf4s2I4oY48MguI8mKtkAjaTw98+nbWbGjntwu8qfhusuVHee3NzgZA6xKD8JmVfLd6ohl5wH9Fr1RF9ymfPPKU= X-Received: by 2002:a62:e908:0:b0:574:53f4:c4d6 with SMTP id j8-20020a62e908000000b0057453f4c4d6mr30626985pfh.81.1669708118501; Mon, 28 Nov 2022 23:48:38 -0800 (PST) MIME-Version: 1.0 References: <20221104085856.18745-1-a.badmaev@clicknet.pro> In-Reply-To: From: Vitaly Wool Date: Tue, 29 Nov 2022 08:48:27 +0100 Message-ID: Subject: Re: [PATCH v6] mm: add zblock - new allocator for use via zpool API To: Johannes Weiner Cc: ananda , linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669708121; a=rsa-sha256; cv=none; b=Db5cUVEz+u2PswZcDPzM81x4NMZAlNOtFtdjFL67lkEuFH88vYY4x7RlCZ5ofMU9aDUkT2 hSVGf2rCXr3TTdWPWDwCph0nP/oTF1VH3p20TxPPOf8ygauoStlrq51E7LgVHkUM3mFN2O tu05vpnaFKvoH+AJIFaU9JfUaPpzD18= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=konsulko.com header.s=google header.b=nPYKrvNb; dmarc=pass (policy=none) header.from=konsulko.com; spf=pass (imf11.hostedemail.com: domain of vitaly.wool@konsulko.com designates 209.85.215.177 as permitted sender) smtp.mailfrom=vitaly.wool@konsulko.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669708121; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=PWU1tUSr5RkkApX8UFtNyIIV+SLqQ7dDSXcXlbOVzkg=; b=NRv+oJEM/ZLf/ZuksztAFZM1rR5OuL78VlBnocRG2z+zutfjhsFEUnfccyN3q2cUEp6aKT /Irc7nVHX19ayHGfs/yC+1QYFoO4FUgPw9J20D/A58do2lk9A0UykAC+ZrD5JTAeB4TEOH eG2P1ViWgn3jppaTLah8Xm50k22AtQY= X-Rspamd-Queue-Id: B98BB4000A X-Rspam-User: Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=konsulko.com header.s=google header.b=nPYKrvNb; dmarc=pass (policy=none) header.from=konsulko.com; spf=pass (imf11.hostedemail.com: domain of vitaly.wool@konsulko.com designates 209.85.215.177 as permitted sender) smtp.mailfrom=vitaly.wool@konsulko.com X-Rspamd-Server: rspam09 X-Stat-Signature: k8ii9ybkd8s1jhgqsr4b81wj3t7686fq X-HE-Tag: 1669708121-606860 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 Mon, Nov 28, 2022 at 9:01 PM Johannes Weiner wrote: > > On Fri, Nov 04, 2022 at 11:58:56AM +0300, ananda wrote: > > From: Ananda > > > > Zblock stores integer number of compressed objects per zblock block. > > What does that mean? It's explained later in the patch but anyway, an example: let's create an object with 4 adjacent pages, a total of 16384 bytes. We can divide it into 43 subblocks of size 381, plus we'll have one byte that's not used. Subblocks will then be treated as an array. > > These blocks consist of several physical pages (1/2/4/8) and are arranged > > in linked lists. > > The range from 0 to PAGE_SIZE is divided into the number of intervals > > corresponding to the number of lists and each list only operates objects > > of size from its interval. Thus the block lists are isolated from each > > other, which makes it possible to simultaneously perform actions with > > several objects from different lists. > > This was benchmarked not long ago in the context of zsmalloc, and it > didn't seem to matter too much in real world applications: > > https://lore.kernel.org/linux-mm/20221107213114.916231-1-nphamcs@gmail.com/ We basically reproduced this test and also ran it with zblock, and zblock performs better by 3.5% on a 8G ZRAM disk with btrfs and this difference is getting bigger with disk sizes getting bigger. I'm pretty sure that the difference will get even bigger over time because zsmalloc will run compaction more and more. > Do you have situations where this matters? > > > Blocks make it possible to densely arrange objects of various sizes > > resulting in low internal fragmentation. Also this allocator tries to fill > > incomplete blocks instead of adding new ones thus in many cases providing > > a compression ratio substantially higher than z3fold and zbud. > > How does it compare to zsmalloc? That depends on the type of data being compressed, but typically zsmalloc is better by 5-10%. > > Zblock does not require MMU and also is superior to zsmalloc with > > regard to the worst execution times, thus allowing for better response time > > and real-time characteristics of the whole system. > > zsmalloc has depends on MMU, but which parts actually require it? It > has its own handle indirection and can migrate objects around and > replace backing pages without any virtual memory tricks. There is the > kmap stuff of course, because it supports highmem backing pages, but > that isn't relevant on NOMMU either. > > Also can you please elaborate on the worst execution time? I don't have the numbers at hand but zsmalloc (and z3fold, for that matter) do have high spikes when compaction kicks in, not to speak about longer disabled preemption. > My first impression is that this looks awfully close to zsmalloc, with > a couple fewer features and somewhat more static design choices. It's > in that sense reminiscent of the slob allocator, which we're in the > process of removing, because 3 slab allocators is a pain to > maintain. This would be the 4th zswap allocator, and it's not clear > that it's drastically outperforming or doing something that isn't > possible in one of the existing ones. I don't think this comparison is on point, at least because zblock's code is at least 4x smaller than zsmalloc's, and the execution overhead is lower too. For lower performance devices, zblock is a real enabler, and there's a class of high performance devices where it can be the best fit too. I get your point about 4 zswap allocators though, and have no problem obsoleting z3fold as soon as we get zblock in. Thanks, Vitaly