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 F2002C4332F for ; Sun, 20 Nov 2022 01:45:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 50C6F6B0074; Sat, 19 Nov 2022 20:45:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4BC9F6B0075; Sat, 19 Nov 2022 20:45:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3844480007; Sat, 19 Nov 2022 20:45:18 -0500 (EST) 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 295436B0074 for ; Sat, 19 Nov 2022 20:45:18 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id D7F87160B14 for ; Sun, 20 Nov 2022 01:45:17 +0000 (UTC) X-FDA: 80152127874.17.72964C6 Received: from mail-pg1-f172.google.com (mail-pg1-f172.google.com [209.85.215.172]) by imf12.hostedemail.com (Postfix) with ESMTP id 7EC164000B for ; Sun, 20 Nov 2022 01:45:17 +0000 (UTC) Received: by mail-pg1-f172.google.com with SMTP id f9so4012348pgf.7 for ; Sat, 19 Nov 2022 17:45:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=o6d5qGnIGRBzKsQXl05dVgjjiXTsNLkw5ORfFj9rjOM=; b=JAAmPXOmxPT2t+wgJzkz1PLrrEl2558J8GWMAZMnFRcNJ0pjf3I1VsAwpTyhsTxjoc 706ptPj9J9tGCrdvoIfaJJ1+EOVpLt6T4UhyqvAZsJpr2zzONvuvP3BV6P10Am80Ldyh msQKGKk1Dn8IaeTQFW+gmxSaI6em4Lo3zUmj4RIQrb1n3K7Ms4wjPAMhIvqnr4jTs5ch 7ncAx9u1zXbWwZsrf7myYnR9YE/RjQC9siba61Y7XZDAOuwGRrjz5/vA9eXMEdSX5o7J 7bjkN+3BxwbflWWoUbi7CfYdEubGolEWkM8grWzXjDp1vaLe6iAzNzrCh4hawFM40fqQ zEvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=o6d5qGnIGRBzKsQXl05dVgjjiXTsNLkw5ORfFj9rjOM=; b=IMZtpLCXs1xHaYSMtBi5GAyOqCvU45MigB1Fhxlv0M8U06Cn8VxPPZwdScmEqufnNd siXfJCADE6bSC45iHVw0fCGHFYksy34eZvf8FexdMSMznuis8SOJG7HC/wZijaQBfYCC hYf3egxR1sbE8fN6voO2LGLm2pCBTpYfdAC2++49Jc3g3hhNnr4WdUrdumfXJVV1S6J1 TPqYdMe7Uzmc/QLedSItbmq6pKieKM357x/3PVdwvSSwN+xw94gEffI8vioq/Gg++V1X CakDMx7KN+NLKMhXkwrxGfikS3zUaq0Mkl8CH02zfiZoIxQFULvix2Ez+UNQ6El+rrH/ LlpQ== X-Gm-Message-State: ANoB5pntsxTncHRXJBOgqLUApy/RH+vN0daisENNoTWSxIb3WXBPiDCP jcI9tcaOeLDtECUworjY8YU= X-Google-Smtp-Source: AA0mqf6OCbjLsFSU4wqNUWleb7x2pCWJyROK5fToPD1F1A4KqPrDcjrrX2KyraQlXgOQwdVld94bxw== X-Received: by 2002:a63:a54d:0:b0:46f:8466:745c with SMTP id r13-20020a63a54d000000b0046f8466745cmr384717pgu.87.1668908716422; Sat, 19 Nov 2022 17:45:16 -0800 (PST) Received: from [192.168.43.80] (subs02-180-214-232-87.three.co.id. [180.214.232.87]) by smtp.gmail.com with ESMTPSA id w1-20020a1709027b8100b00181e55d02dcsm6472540pll.139.2022.11.19.17.45.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 19 Nov 2022 17:45:16 -0800 (PST) Message-ID: Date: Sun, 20 Nov 2022 08:45:12 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [PATCH v7] mm: add zblock - new allocator for use via zpool API To: Ananda Badmaev Cc: linux-mm@kvack.org, vitaly.wool@konsulko.com, Linux Doc Mailing List References: <20221119082159.63636-1-a.badmaev@clicknet.pro> Content-Language: en-US From: Bagas Sanjaya In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668908717; a=rsa-sha256; cv=none; b=dFY3obtrdtamuicbul9OZDXA/D68xSrQtJBf1+++1sLrdoDHW2w1oFzNRnWl1t3w5QoPXc jxsRqBWnVSM8lG2ZzHypegC9j3SPmDmGpM0UoBZmEmSyfXLN9JT18DnCKDnmEY5eQH27fE /lWSLz0AyYCQZ8vDggtFLyqdCgOJULI= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=JAAmPXOm; spf=pass (imf12.hostedemail.com: domain of bagasdotme@gmail.com designates 209.85.215.172 as permitted sender) smtp.mailfrom=bagasdotme@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668908717; 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=o6d5qGnIGRBzKsQXl05dVgjjiXTsNLkw5ORfFj9rjOM=; b=edwffxodpwxtFTtFxukAUGYR4/O7RLizn5ZD7DbGrUXt+MchJfqedRgmLXuAlPjts8O63R WpeV3s/uqnc2GgzPoTTDxqEWowhiw0hzrkwClBiH6dIvb8Do+8uIEy7EhxVatvgTuRz5LL hiTy49Cd+OegIsfBYmRVBEobXFMLg1s= X-Stat-Signature: m95wu4u6kkasykpuu6yuy1gwuqixam1h X-Rspamd-Queue-Id: 7EC164000B Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=JAAmPXOm; spf=pass (imf12.hostedemail.com: domain of bagasdotme@gmail.com designates 209.85.215.172 as permitted sender) smtp.mailfrom=bagasdotme@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam04 X-Rspam-User: X-HE-Tag: 1668908717-932475 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 11/20/22 00:24, Ananda Badmaev wrote: > 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. > OK, thanks. Next time, don't forget to Cc linux-doc list for patches touching Documentation/. Adding one since you don't. -- An old man doll... just what I always wanted! - Clara