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 270D7C433FE for ; Sat, 19 Nov 2022 12:46:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 47AF56B0072; Sat, 19 Nov 2022 07:46:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 42B106B0073; Sat, 19 Nov 2022 07:46:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2F2346B0074; Sat, 19 Nov 2022 07:46:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 1CDD96B0072 for ; Sat, 19 Nov 2022 07:46:20 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id CAD3E140752 for ; Sat, 19 Nov 2022 12:46:19 +0000 (UTC) X-FDA: 80150164878.28.41848F1 Received: from mail-pj1-f52.google.com (mail-pj1-f52.google.com [209.85.216.52]) by imf25.hostedemail.com (Postfix) with ESMTP id 733FBA0010 for ; Sat, 19 Nov 2022 12:46:19 +0000 (UTC) Received: by mail-pj1-f52.google.com with SMTP id t17so6055098pjo.3 for ; Sat, 19 Nov 2022 04:46:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=4hTwG8olcEpKalTpbs7nbrSIktg0k8CQsNp/+VGTvI8=; b=iOQnGtYK8F2oY/64vPBVTGws79Js7M9ZL3M+nmxbO2IoP1v3rFUWVwEklZiDDHYx2C d8IBNqQF5C2KdBL5rZ/c8rHYL7cCHQDZPByWk491KfWCJ2/PHfK4OZe/aKhuVp9/o/yR zyGDxXufOCHo0jYpan1YpKs3VlLNzyfGb+a/EaYeiG4iMNjP2FLQrlEJKIiUHyLbRBkJ ZucdSVkkvBbRl0rxxR/wxj1YRM9gvarjL5m94qQu6nzTu7AhsDcX/ISCrkOoywZdDc9M vj3CPFAlVaN0oyfBHqjvp1nOyd6iTCXyqhAIE5zWy5FbtwLDNiMeICbggbiM4wRMy1vu lmow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=4hTwG8olcEpKalTpbs7nbrSIktg0k8CQsNp/+VGTvI8=; b=JQ4WdwduS2nDDUwhBqmWjHqnLLjN7jc4cUA02GVsDeMQjA5zlhXfViuzYEiFvOLcvU fk7B8mB3zKXBcE3OS7IMGUmOMEi8y4J/XjIOr+4eGO/tQVVRiALMHlVlUlRVFlP4+72Q o2MEWsVy/AdK97jEJicPAjeAlb9MOjaDGG13QxVquBHXnBHY38IEgKwmmMW2F6Fp85K+ uc9ymvxlpUfE+YlLoQ0QAOSSiXwB0uSM1hxfTLTKl1GPMjK8lPxcdXQFU55kcDQhRWBF 2LwzphD3wChBtzkOVIdZqLTP5rs//oppb/mKVdTGZaE+7NkzJauaBjCKeCPCqeUzaNq1 z/nQ== X-Gm-Message-State: ANoB5pkF4lh/lRVF0SyO/1BC7IdaA29xWF2CDWS+Bbg9OQ5+2GoqYV1v 6ktEuj9CWI6rE9rjlPQegJ0= X-Google-Smtp-Source: AA0mqf4tN4A4t3rhoBL6PU/AALG2p4EVbWzPp5KXM2BjNhnASua+PKs2k6IDrRzVO64OGPoKbLa3MA== X-Received: by 2002:a17:90a:d145:b0:211:7e51:9d65 with SMTP id t5-20020a17090ad14500b002117e519d65mr17642341pjw.220.1668861978225; Sat, 19 Nov 2022 04:46:18 -0800 (PST) Received: from debian.me (subs32-116-206-28-4.three.co.id. [116.206.28.4]) by smtp.gmail.com with ESMTPSA id q15-20020aa7842f000000b0056b9df2a15esm5029888pfn.62.2022.11.19.04.46.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 19 Nov 2022 04:46:17 -0800 (PST) Received: by debian.me (Postfix, from userid 1000) id A94C61039F2; Sat, 19 Nov 2022 19:46:13 +0700 (WIB) Date: Sat, 19 Nov 2022 19:46:13 +0700 From: Bagas Sanjaya To: ananda Cc: linux-mm@kvack.org, vitaly.wool@konsulko.com Subject: Re: [PATCH v7] mm: add zblock - new allocator for use via zpool API Message-ID: References: <20221119082159.63636-1-a.badmaev@clicknet.pro> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dKGqjqjHYIeyv8W0" Content-Disposition: inline In-Reply-To: <20221119082159.63636-1-a.badmaev@clicknet.pro> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668861979; a=rsa-sha256; cv=none; b=h8D4wxpOBAHcX23EOv2nwNZ/C1JDT9bplG1KkCjteLkQ0o39r1mnQTqPFtTnvqD45S9aW+ zMqmJ0BuoqsX+6HPi1pl8G9e/e0ZltpnKa2G8bVWEBNNnUu01oFcv5Md2l3kU3R6Gzvrmm rQq/QTJwYl/aBkM71DFnfmludZ8KZNw= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=iOQnGtYK; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf25.hostedemail.com: domain of bagasdotme@gmail.com designates 209.85.216.52 as permitted sender) smtp.mailfrom=bagasdotme@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668861979; 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=4hTwG8olcEpKalTpbs7nbrSIktg0k8CQsNp/+VGTvI8=; b=hMa3EYhNQlX7WMO//WR5dupvKmTf6GO8kenFt9o9ZVS2MRMFGN8cKoU9w6jwPnh3FyE2LM mC84WQAiQlz7cXFV9y3yd4LqDtmhZJB4oGsUl05V+KK3v0TLOuENuhwnP4UruGAJiiS3bu jTLvkANPuCScDzCWgXK78LVC7zw34Vo= X-Stat-Signature: hnbhfgdbq4n6dj9mjue6udh13oi6rf6y X-Rspamd-Queue-Id: 733FBA0010 Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=iOQnGtYK; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf25.hostedemail.com: domain of bagasdotme@gmail.com designates 209.85.216.52 as permitted sender) smtp.mailfrom=bagasdotme@gmail.com X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1668861979-235588 X-Bogosity: Ham, tests=bogofilter, spamicity=0.193195, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: --dKGqjqjHYIeyv8W0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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? > + > +=3D=3D=3D=3D=3D=3D > +zblock > +=3D=3D=3D=3D=3D=3D > + > +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 fi= ll > +incomplete blocks instead of adding new ones thus in many cases providing > +a compression ratio substantially higher than z3fold and zbud. Zblock do= es > +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 =20 -.. _block: +.. _zblock: =20 =3D=3D=3D=3D=3D=3D zblock =3D=3D=3D=3D=3D=3D =20 -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 arrang= ed in +lists. The range from 0 to PAGE_SIZE is divided into the number of interva= ls +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 obj= ects +from different lists. =20 -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. Zb= lock +does not require MMU and also is superior to zsmalloc with regard to the w= orst execution times, thus allowing for better response time and real-time characteristics of the whole system. =20 -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() do= es +not return a dereferenceable pointer. Instead, it returns an unsigned long +handle which encodes actual location of the allocated object. =20 -Unlike zbud and z3fold zblock works well with objects of various sizes - b= oth -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 w= ell +as cases where both object types exist. Thanks. --=20 An old man doll... just what I always wanted! - Clara --dKGqjqjHYIeyv8W0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQSSYQ6Cy7oyFNCHrUH2uYlJVVFOowUCY3jQDwAKCRD2uYlJVVFO oyc+AP0cYGy1bnmnKEdw3W9+1rHITJF30aKIZwDrgFBn98oS4wEA94P6Zf8X7MRK aBqXEbaZ7gVa0u2Hs5U68fgbqNh62As= =ja+P -----END PGP SIGNATURE----- --dKGqjqjHYIeyv8W0--