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 87AE3C07E9D for ; Thu, 29 Sep 2022 05:25:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0CC488D0002; Thu, 29 Sep 2022 01:25:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 07BAB8D0001; Thu, 29 Sep 2022 01:25:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EACC68D0002; Thu, 29 Sep 2022 01:25:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id DC4F18D0001 for ; Thu, 29 Sep 2022 01:25:15 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id AF6EC1A0B06 for ; Thu, 29 Sep 2022 05:25:15 +0000 (UTC) X-FDA: 79963984590.18.BB41099 Received: from forward501p.mail.yandex.net (forward501p.mail.yandex.net [77.88.28.111]) by imf06.hostedemail.com (Postfix) with ESMTP id EE52D180002 for ; Thu, 29 Sep 2022 05:25:13 +0000 (UTC) Received: from myt6-9bdf92ffd111.qloud-c.yandex.net (myt6-9bdf92ffd111.qloud-c.yandex.net [IPv6:2a02:6b8:c12:468a:0:640:9bdf:92ff]) by forward501p.mail.yandex.net (Yandex) with ESMTP id 336D46212968; Thu, 29 Sep 2022 08:25:11 +0300 (MSK) Received: by myt6-9bdf92ffd111.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id MimdElEFEP-PAhWC71E; Thu, 29 Sep 2022 08:25:10 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=clicknet.pro; s=mail; t=1664429110; bh=h/RUfPnMzNVEWhseNP/7UMSmOAAu+DDr/hekqFG4vJg=; h=From:In-Reply-To:Cc:Date:References:To:Subject:Message-ID; b=tZkR4BAHScX4m1uOVyo3SWTJnas7T/V/sw+yDrQsMhWl0JeTIlq8cR1AGY9MQE+s6 c0K7QHAku+Dk8AE9bW1IsKx/uFOCxhhWue6h1XD60OotZZ9Li4HTo+vHLNdBHHjHyZ zxJtzhRmW7+s1CP7TvaXrsTt28U9FWAVjtbEV4Xo= Message-ID: Date: Thu, 29 Sep 2022 08:24:55 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH v5] mm: add zblock - new allocator for use via zpool API Content-Language: en-US To: Yosry Ahmed Cc: Linux-MM , vitaly.wool@konsulko.com References: <20220928080100.19134-1-a.badmaev@clicknet.pro> From: Ananda Badmaev In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1664429114; a=rsa-sha256; cv=none; b=Kfs9np0R81sMR0wJSVjAC90wZOtPfWhIegFJ2kk08hXniFq4ElETPap8R3auBvcpc2yPGJ vOF2OkjMJzsgLtNaAyqqzMOlPZX0ESC6EFycRQSr0/TcOa9hwJjpe1ISUpzdZknrbKy68P Cr0beuFzWowDdQilA1skE4NmMwlm/bI= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=clicknet.pro header.s=mail header.b=tZkR4BAH; dmarc=none; spf=pass (imf06.hostedemail.com: domain of a.badmaev@clicknet.pro designates 77.88.28.111 as permitted sender) smtp.mailfrom=a.badmaev@clicknet.pro ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1664429114; 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=h/RUfPnMzNVEWhseNP/7UMSmOAAu+DDr/hekqFG4vJg=; b=ZDcBv17QE6E967ud7HtSRdrePhe3Xkfr8uVug+My2l8eiCqCsd2e76ay108GAmIHWUNxDu i76RaepyVaoRTo9sab4ZSfITU65kqFrdRE/TYUZnxVxbkKRQtp6eSb+MDINcGnlDAbbvot YSL9Nf2z71qg/WYlXjHGFv7uJQf0Frs= X-Stat-Signature: skxznq1ks8dsf4rrqcsj411xt6rnb9ei X-Rspamd-Queue-Id: EE52D180002 Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=clicknet.pro header.s=mail header.b=tZkR4BAH; dmarc=none; spf=pass (imf06.hostedemail.com: domain of a.badmaev@clicknet.pro designates 77.88.28.111 as permitted sender) smtp.mailfrom=a.badmaev@clicknet.pro X-Rspamd-Server: rspam02 X-Rspam-User: X-HE-Tag: 1664429113-629935 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: 28.09.2022 21:37, Yosry Ahmed пишет: > On Wed, Sep 28, 2022 at 1:06 AM ananda wrote: >> >> From: Ananda >> >> Zblock stores integer number of compressed objects per zblock block. >> 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. >> 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. >> 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. >> > > It seems to me, and I can be wrong, that there is some overlap in > design and goals between this zpool backend and zsmalloc. They both > try to avoid internal fragmentation by avoiding the static slots used > by zbud and z3fold, and instead pack compressed pages more > dynamically. They both have some sort of concurrency handling > (separate block lists in zblock vs. classes in zsmalloc). A key > difference is that zsmalloc avoids higher order allocations (at least > based on its docs), and instead allows compressed pages to span across > 0-order page boundaries. You are right. > The key differences I see here (based on this commit message and > zsmalloc docs) are: > a) Blocks in zblock can consist of higher order pages. > b) Compressed pages in zsmalloc can span page boundaries (I am > assuming this isn't the case for zblock). > > It appears to me that if zblock has better performance than zsmalloc, > it can be because pages in zblock are physically contiguous vs. the > 0-order pages in zsmalloc (TLB misses, cache misses, etc). Is my > assumption correct? > Yes. > If yes, would it be better to implement those changes as some tunable > extension to zsmalloc? It would make it easier if we have overall less > zpool backends, and also easier for current users of zsmalloc to > experiment with these changes. > Sounds reasonable, but I'm afraid in this case zsmalloc code will become overloaded also there might be problems with keeping zblock simplicity.