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 14C95C4332F for ; Sat, 19 Nov 2022 17:25:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 43A4B6B0072; Sat, 19 Nov 2022 12:25:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3EA596B0073; Sat, 19 Nov 2022 12:25:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2B2CD6B0074; Sat, 19 Nov 2022 12:25:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 1AC3B6B0072 for ; Sat, 19 Nov 2022 12:25:19 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id E0FF8AAFE7 for ; Sat, 19 Nov 2022 17:25:18 +0000 (UTC) X-FDA: 80150867916.17.60B549F Received: from forward502o.mail.yandex.net (forward502o.mail.yandex.net [37.140.190.204]) by imf20.hostedemail.com (Postfix) with ESMTP id CCBCB1C0006 for ; Sat, 19 Nov 2022 17:25:17 +0000 (UTC) Received: from iva5-344f444591f3.qloud-c.yandex.net (iva5-344f444591f3.qloud-c.yandex.net [IPv6:2a02:6b8:c0c:687:0:640:344f:4445]) by forward502o.mail.yandex.net (Yandex) with ESMTP id 8F53725D40B6; Sat, 19 Nov 2022 20:25:15 +0300 (MSK) Received: by iva5-344f444591f3.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id ii5W7CBooe-PEg0ncIG; Sat, 19 Nov 2022 20:25:15 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=clicknet.pro; s=mail; t=1668878715; bh=IJXq10+87sNM5Fu6QNK/3TT2nWNpAA4WXRALnidWiqU=; h=From:In-Reply-To:Cc:Date:References:To:Subject:Message-ID; b=UK2rNKSZccqnO8ooDg6KfHUnaATnPjEnfa6JF+oWiCt3YGjRQIVDTTBekAMip2s4u blf1vKXUxwN/I6xcSErsC3/lK4iMgsts5gnrlqOPNwOgd+nTK0CrvQhv/w+Hryanwe x+LWn13U4l3nquaWvBsTVXxn5eijb7SPF3GxTEbg= Message-ID: Date: Sat, 19 Nov 2022 20:24:59 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: [PATCH v7] mm: add zblock - new allocator for use via zpool API Content-Language: en-US To: Bagas Sanjaya Cc: linux-mm@kvack.org, vitaly.wool@konsulko.com References: <20221119082159.63636-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=1668878718; a=rsa-sha256; cv=none; b=JkJnyvM3YywDfQBJ5182lTTzd5T6orCodlW1eIr7uUq15LKngBISmlLwguTUCvxJLd7EIS 1Rz6WlHQ5g7GIIzt60oen7/yU1pN12PCoT0/CJC8M/mlRyLQ01VRF6NzxByovgmCO85ZWI N9xZkQnynUIfNvyfX0IFsF4mBKNWr60= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=clicknet.pro header.s=mail header.b=UK2rNKSZ; dmarc=none; spf=pass (imf20.hostedemail.com: domain of a.badmaev@clicknet.pro designates 37.140.190.204 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=1668878718; 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=IJXq10+87sNM5Fu6QNK/3TT2nWNpAA4WXRALnidWiqU=; b=VCi90WEQt6tYCeuDmWM4PhCg94fxyTuNijVqrSP0p9KcnW8CxVDh0E35QnVfpGUD77EfBF fPcqBhCupwnVkrS6Q9HlkEctuzmL8oUDxGHVDtG3zBHVIZ3IBOqcr8aH3/WLGUibJvZbZ6 xNq/l1JQY31nIIQACpuVcP5RPigHea4= X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: CCBCB1C0006 Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=clicknet.pro header.s=mail header.b=UK2rNKSZ; dmarc=none; spf=pass (imf20.hostedemail.com: domain of a.badmaev@clicknet.pro designates 37.140.190.204 as permitted sender) smtp.mailfrom=a.badmaev@clicknet.pro X-Stat-Signature: rwgn5ji39x13aisdiwp7ta18exxdfr1b X-HE-Tag: 1668878717-343610 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000030, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 19.11.2022 15:46, Bagas Sanjaya пишет: > On Sat, Nov 19, 2022 at 11:21:59AM +0300, ananda wrote: >> +.. SPDX-License-Identifier: GPL-2.0 >> + >> +.. _block: > > Why is the anchor label for doc title _block? Why not _zblock instead? > This is a typo. It will be fixed in the next version if necessary. >> + >> +Zblock stores integer number of compressed objects per block. These >> +blocks consist of several consecutive physical pages (from 1 to 8) and >> +are arranged in 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. >> + >> +Like z3fold and zsmalloc zblock_alloc() does not return a dereferenceable >> +pointer. Instead, it returns an unsigned long handle which encodes actual >> +location of the allocated object. >> + >> +Unlike zbud and z3fold zblock works well with objects of various sizes - both >> +highly compressed and poorly compressed including cases where both types >> +are present. > > The wording can be better (including doc title label suggestion): > > ---- >8 ---- > > diff --git a/Documentation/mm/zblock.rst b/Documentation/mm/zblock.rst > index 5008ce90b54bef..1eb91a8d175dbb 100644 > --- a/Documentation/mm/zblock.rst > +++ b/Documentation/mm/zblock.rst > @@ -1,31 +1,31 @@ > .. SPDX-License-Identifier: GPL-2.0 > > -.. _block: > +.. _zblock: > > ====== > zblock > ====== > > -Zblock stores integer number of compressed objects per block. These > -blocks consist of several consecutive physical pages (from 1 to 8) and > -are arranged in 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. > +Zblock stores integer number of compressed objects per block. These blocks > +consist of several consecutive physical pages (from 1 to 8) and are arranged in > +lists. The range from 0 to PAGE_SIZE is divided into the number of intervals > +corresponding to each list and these only operates on objects of size from the > +corresponding 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 > +With zblock, it is 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 > +incomplete blocks instead of adding new ones. As a result, in many cases it > +provides 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. > > -Like z3fold and zsmalloc zblock_alloc() does not return a dereferenceable > -pointer. Instead, it returns an unsigned long handle which encodes actual > -location of the allocated object. > +Like similar allocation method from z3fold and zsmalloc, zblock_alloc() does > +not return a dereferenceable pointer. Instead, it returns an unsigned long > +handle which encodes actual location of the allocated object. > > -Unlike zbud and z3fold zblock works well with objects of various sizes - both > -highly compressed and poorly compressed including cases where both types > -are present. > +Unlike zbud and z3fold, zblock works well with objects of various sizes - > +including but not limited to highly compressed and poorly compressed, as well > +as cases where both object types exist. > > Thanks. > I'm not sure there's much point in simply reformulating the text, but in the next version it may be worth a bit changing this text along with other changes.