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 2F19BECAAD3 for ; Mon, 5 Sep 2022 10:06:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9CB0F801D2; Mon, 5 Sep 2022 06:06:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 97A368D0050; Mon, 5 Sep 2022 06:06:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 841CF801D2; Mon, 5 Sep 2022 06:06:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 744E58D0050 for ; Mon, 5 Sep 2022 06:06:16 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 33E001C1371 for ; Mon, 5 Sep 2022 10:06:16 +0000 (UTC) X-FDA: 79877601552.13.0DCCEC6 Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com [209.85.218.53]) by imf03.hostedemail.com (Postfix) with ESMTP id EA7E22005F for ; Mon, 5 Sep 2022 10:06:15 +0000 (UTC) Received: by mail-ej1-f53.google.com with SMTP id nc14so16025944ejc.4 for ; Mon, 05 Sep 2022 03:06:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=CCsjW2ihj3ub+9/+LDmvPPjSWhHhWWtp7N+Zepi/39Y=; b=oHAZeqW2U8L71CZoOZtH1/y98LVWEMlURbJLey/QyPpyChU9dmTRk+W2x4ws4Tw6nQ DSCYlOWNOwepWtTneN215b2TQYJz7qKVriScywgG1a5fEKBQIR26zqjhCBqw0HGoKOpa npTL9N2l2AwGcAEyN9bRSm2eHTFVQx6YcKJi/n0nQgtdRplDwPC7/JjjkI3zzfDwQf+J wngGdQ6gWXcY0aLVQrWPsiqWxPaomA34AzsN49BaG69C411K5snO3MBd28kzaM/qcnqV w54bNmHzSPt50p1QHmHMKlQoJ2LzjPXyNezDe2XmLL5KI6qYdJSQJNrkulew2tmywKwY iSOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=CCsjW2ihj3ub+9/+LDmvPPjSWhHhWWtp7N+Zepi/39Y=; b=P+7vjZlIcxkMQCJ5YO4OpARgxm6MnVUNnZu0mMQej+2vAlQxTQoMRK2pZpZLrBJkTq 3Lvgyn9acM2eZX/Aef/8TnlzPaCEby3k7o/aNrZnV/K985+kXMaD0NWhLxvAB8m5bkQb XFdRpS1R1vjGD1qBOdlHoT/gXHFCEEd+u7LdZaVejHml3r5OpOEy9+soL7+ARlIiDGYi SojkscWbj9YBvetTV5xEKijr8h38aLyBmv6kqiMCKADROOsdPA8Ki1V7gL4Zh9nDf/Is QgrzeyJc4dFZuCSmOersN5qFycQ0PD0o27i351JCVK2rsGiQYJ45IakDLQIoZ92G5zae fzmg== X-Gm-Message-State: ACgBeo0HnjcAQXN68KIpWJJBDFQeu93Mrw+6Ud468MCx4bXS8h+7om3l AfUqehO9NlYrJlTEyVyZTS9A1Nosfl1Fgw9B1+A= X-Google-Smtp-Source: AA6agR4XmCqRrivqKqPnefhDNeWZBexPCoGlW8Un49/pYDOQDuTy8dBANcs+Bj7DR5pDZsd+8tsirkyf326P95S7KKE= X-Received: by 2002:a17:907:7d8c:b0:731:65f6:1f28 with SMTP id oz12-20020a1709077d8c00b0073165f61f28mr33463880ejc.91.1662372374610; Mon, 05 Sep 2022 03:06:14 -0700 (PDT) MIME-Version: 1.0 References: <20220905081552.2740917-1-senozhatsky@chromium.org> <20220905081552.2740917-8-senozhatsky@chromium.org> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Mon, 5 Sep 2022 22:06:00 +1200 Message-ID: Subject: Re: [PATCH RFC 4/7] zram: Introduce recompress sysfs knob To: Sergey Senozhatsky Cc: Minchan Kim , Andrew Morton , Nitin Gupta , linux-kernel@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662372375; a=rsa-sha256; cv=none; b=qrr/L9Y8ccne3uxLLzadcXdPZtM8BP8CasPWmQ7EWJ2xDchTQrxtsT3znbF/yzos+wTBeX tTBzz9dvM2jTBGID5Yy/L9WLRXNDKrkgfO3whKNIIaUpbwGkejXZcgM1e3he7kzfUmNAKi Z45PSGWZ+CxjWyTIqI7hdQKfj709HGU= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=oHAZeqW2; spf=pass (imf03.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.218.53 as permitted sender) smtp.mailfrom=21cnbao@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=1662372375; 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=CCsjW2ihj3ub+9/+LDmvPPjSWhHhWWtp7N+Zepi/39Y=; b=5pW7QumwSuYpchkmDlnGA5uzMx7OwWwsS7GKwGWb8W5331HwMHofAlhltixke5yfeX6oK3 9P/f4VrrIStHoF1rl0kkMKMl94MbG9o3gsntXgnhCdZGxN2fjqtPPDX0lpcHBqWT9fipcA B4u8WejPtsK4+wy5ig0qNENlSSxBBfE= Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=oHAZeqW2; spf=pass (imf03.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.218.53 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspam-User: X-Rspamd-Server: rspam12 X-Stat-Signature: 4cy7xpzkcrfy6fo4ewsmm5os5jbypt3c X-Rspamd-Queue-Id: EA7E22005F X-HE-Tag: 1662372375-191099 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000651, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Sep 5, 2022 at 9:53 PM Sergey Senozhatsky wrote: > > 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. make sense! thanks! i assume you will have some benchmark data to compare three cases, 1. lzo with recompress zstd 2. always use lzo 3. always use zstd such as power consumption, cpu utilization, available memory, benefits to user experiences especially to UI smoothness under memory pressure? Thanks Barry