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 1586EECAAD3 for ; Mon, 5 Sep 2022 09:53:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7F175801D1; Mon, 5 Sep 2022 05:53:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7A0C08D0050; Mon, 5 Sep 2022 05:53:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 66801801D1; Mon, 5 Sep 2022 05:53:32 -0400 (EDT) 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 56BC48D0050 for ; Mon, 5 Sep 2022 05:53:32 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 328D9801BF for ; Mon, 5 Sep 2022 09:53:32 +0000 (UTC) X-FDA: 79877569464.29.4566AED Received: from mail-pj1-f44.google.com (mail-pj1-f44.google.com [209.85.216.44]) by imf19.hostedemail.com (Postfix) with ESMTP id A2CFC1A0059 for ; Mon, 5 Sep 2022 09:53:31 +0000 (UTC) Received: by mail-pj1-f44.google.com with SMTP id t11-20020a17090a510b00b001fac77e9d1fso11671812pjh.5 for ; Mon, 05 Sep 2022 02:53:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=8Ckz0T6YNnRZNu6cs7oBc7l4oyTpQLkMjPQRiuxKr9A=; b=VbV7NOz/Y2gcFfjBM3bnmNQCtYFvbrvzA+PXrumrjqjaEUtKilSdW73tUz64K6Af81 wO02ZsCWC/EQwZma9FCedhKBMXOidF8NB3p3iQ11AwkKsTTg7c9u/eovOWZ+VJcYOVIq Ub3diOK3sgT3EAi0vyEgNixzfN0NcK7NAUOtY= 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; bh=8Ckz0T6YNnRZNu6cs7oBc7l4oyTpQLkMjPQRiuxKr9A=; b=5xAr3kW/2nhtY2hZFnm67FpJ0ZfPJEZKvfHxjEb64jcISoN2M2sGW9dwjJYOP5Lo9q Z92RJ6siGs1iYvQya0MVxLH3KjI5NC9R2FwNtblzmsWif7JM3Yzyy56qXLTaXN1gfmgp mb2ChZQmadfC4waRinoQAief5AuR3IIFZTWZKdJy1xwq7IlyAxredwY/6wg45iUKQKqR dEVrP7B5h+ja2zfTtUWek9UQUyGUx+N92O2JIQqpbwIyo7MYH4iRUsPkX6LRtloTFXIx qUHTQGHONuHnEdwcCArfkotLA2Eha3wUwOuCuwy7V0o4u4Vq3hKVdAHYOW3XYd+9d4Kg OoIg== X-Gm-Message-State: ACgBeo04Fr26vwuU3QCjNe0jWikO8vdaIQzKk8jmuD507lwbce4ScEvN smZe7dhyZZ2JEQEKmOIfjxA2cA== X-Google-Smtp-Source: AA6agR7JuqhxfhOtl79bH8xHHuicCKPpy4VEo0nWZu56Y7UpZSZXLWXJiSULunOrGkAW1f7fY7S7ig== X-Received: by 2002:a17:90a:4805:b0:1f5:39ab:29a9 with SMTP id a5-20020a17090a480500b001f539ab29a9mr18487717pjh.202.1662371610474; Mon, 05 Sep 2022 02:53:30 -0700 (PDT) Received: from google.com ([240f:75:7537:3187:5167:aa6c:9829:64dd]) by smtp.gmail.com with ESMTPSA id n9-20020a170902d2c900b001755ac7dd0asm2582035plc.290.2022.09.05.02.53.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Sep 2022 02:53:29 -0700 (PDT) Date: Mon, 5 Sep 2022 18:53:25 +0900 From: Sergey Senozhatsky To: Barry Song <21cnbao@gmail.com> Cc: Sergey Senozhatsky , Minchan Kim , Andrew Morton , Nitin Gupta , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH RFC 4/7] zram: Introduce recompress sysfs knob Message-ID: References: <20220905081552.2740917-1-senozhatsky@chromium.org> <20220905081552.2740917-8-senozhatsky@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662371611; a=rsa-sha256; cv=none; b=n+FyYGc/mf7sbBT51xZPa4d1DtLJWj87UnDyUN4aQnFjj2UIKc8w9Tk5hxOMClTw4SjFWK auGqxnMY+cpB6pWxZIWFdWQ/dOc+5FvYiuedPt5FadXSk+471ekgW6lotgQQK7jcATgLru 1VfzHvx9ON/kvjNJqTFcxbyfe321FlQ= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="VbV7NOz/"; spf=pass (imf19.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.216.44 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662371611; 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=8Ckz0T6YNnRZNu6cs7oBc7l4oyTpQLkMjPQRiuxKr9A=; b=DD1kaJwjxbBkghQWrvG9itHnzoGRn2XaWAWBoyB1//SqrrTW1/FAo1VGBWVQX5C9yWBbA4 4K8oSQJ9tLfcCj3rfTZWnNGOd0FoWD1HUaWqkqiG/1MWRKHiFr0QZaPFTyTAt7ycPC/ZTj tpl7DVNektzqwBx58P71vtJBUovii8Y= Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="VbV7NOz/"; spf=pass (imf19.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.216.44 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org X-Rspam-User: X-Rspamd-Server: rspam12 X-Stat-Signature: 1n98oiop9qb7ato6urdkfkokmcwgm989 X-Rspamd-Queue-Id: A2CFC1A0059 X-HE-Tag: 1662371611-185697 X-Bogosity: Ham, tests=bogofilter, spamicity=0.007072, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On (22/09/05 21:21), Barry Song wrote: > > 3) HUGE pages recompression is activated by `huge` mode > > > > echo huge > /sys/block/zram0/recompress > > Thanks for developing this interesting feature. It seems reasonable for cold > pages. But for a huge page, do you have some data to show that the hugepage > is not compressed by lzo/lz4 so we need zstd further? i assume the size of > the huge page you are talking about is 2MB? Oh, yeah, this is the lingo we use in zram. We used "huge" object and "huge" size class in zsmalloc and the term "huge" transitioned to zram, but zram operates with pages not objects, so huge zsmalloc object is "huge zram page". > on second thoughts, it seems you mean hugepage is those pages > whose compressed data is big? if so, can you please avoid using > "huge page" as it is quite misleading in linux. we are using hugepage > for pages larger than 4KB. Yes, you are right. And I wish I could use a different term, but... this is what zram has been using for many years: Documentation/admin-guide/blockdev/zram.rst And we already accept "huge" and "huge pages", and so, in sysfs knobs (zram device attrs), so the confusing term, unfortunately, is there forever.