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 D1C1AECAAD5 for ; Mon, 5 Sep 2022 10:17:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4C5518D0060; Mon, 5 Sep 2022 06:17:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4754E8D0050; Mon, 5 Sep 2022 06:17:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 33EE48D0060; Mon, 5 Sep 2022 06:17:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 2535E8D0050 for ; Mon, 5 Sep 2022 06:17:59 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id EF56E807D9 for ; Mon, 5 Sep 2022 10:17:58 +0000 (UTC) X-FDA: 79877631036.30.59C7596 Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) by imf15.hostedemail.com (Postfix) with ESMTP id 9D884A0062 for ; Mon, 5 Sep 2022 10:17:58 +0000 (UTC) Received: by mail-pj1-f42.google.com with SMTP id fs14so3208981pjb.5 for ; Mon, 05 Sep 2022 03:17:58 -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=F0ddXFVLxsyluskjlQCTzOkpXw/Iq5ze8DpeLG6TX/8=; b=ZKiFiuxy/bJNdyZsis/2GMHJnWZKLPLWmKNo/OlfL+iAGLD/H/nqM6nR8jgAXrij+O n46QHM71KCKpys9Js1hB0qdJa4QA4gOky5ZHGuiPTesuRIW2o2YhrAdahEVazSdipXqG eNhOMzXg6X6bL2uLwlvFY3gDtD6BmMIFmTuqE= 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=F0ddXFVLxsyluskjlQCTzOkpXw/Iq5ze8DpeLG6TX/8=; b=GBE9vmaocoQWG/Y5dnuks6CFwoMyFHHubnswvF7XXRybqkWUCORi6gb/TDloOF7faw NmugRmML/8fkibXbvid6A0p+xQKiPkJBa3hvIsnEQemVt5q8mZmS6Zoo+RJXkIktPmre m3S0nLLRFo8HDVh9jGBawJ00EQHx89V89r04YvR0IUy6+aVfeerjE5FgGnEPFfJNQxRZ M9bQ9N8ZLYrm0SqmVQgmxTi4nHh1vDOjBcrNava48tV7becWOOjBOhX77ySmDqJOnvRf g8hs75R+WKSi0nAFsV7p0JEmiJRsKuVL7+h6EgBl42vxJxmfpuLP6EGmFBSiTWsBjYIf wR0Q== X-Gm-Message-State: ACgBeo2t3cC2QuT+txka7ZSm9eR6qDWT53k7ySZbA275kPPKv5oxwACN iOJ3Ksjvf/LlTKpqODMJ1VKziQ== X-Google-Smtp-Source: AA6agR7cQ6Kdc7lDA6p+oTLhOt05qMwgjkaiG/8Sj4vFtvXw6tmM2bKARpAGBYRvbaAPM0qvjdAywg== X-Received: by 2002:a17:90a:6b4c:b0:1fa:d973:e4eb with SMTP id x12-20020a17090a6b4c00b001fad973e4ebmr18424093pjl.15.1662373077690; Mon, 05 Sep 2022 03:17:57 -0700 (PDT) Received: from google.com ([240f:75:7537:3187:5167:aa6c:9829:64dd]) by smtp.gmail.com with ESMTPSA id v28-20020aa799dc000000b00537ab89c66csm7630564pfi.143.2022.09.05.03.17.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Sep 2022 03:17:57 -0700 (PDT) Date: Mon, 5 Sep 2022 19:17:52 +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=1662373078; a=rsa-sha256; cv=none; b=cmcLau8LnA+EJhqXdkCFy3iWmeQcpOhI/y9G0/oCo+qQpHrtKc+5Ij1i86CTpYpQ5N3DRL 5sDoBEYgXsIMvGlUlJSpUGMXOCnvppnAvtvH6aSgBCzlzl1mPynBgfx9rAhQIAXtVrkcXi SoaStg/MnHxH/2XSND7kfl+pnVEPbuQ= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=ZKiFiuxy; spf=pass (imf15.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.216.42 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=1662373078; 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=F0ddXFVLxsyluskjlQCTzOkpXw/Iq5ze8DpeLG6TX/8=; b=L90/r/7Zgd3dbca82AF192WRxgkrfAw72nc8mR6g3+6M/WmS+GOWmGbuHsKoq6SWPWn2lJ fkQYebrcITtQKOL8NjZczSrJ6j1XCmlOWvcQsxQuL8D60culbge+E1jjIm7huhKh+5DTiW WtOV9LSnQpw/nTJLaMKMtzj1NJqxb+g= Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=ZKiFiuxy; spf=pass (imf15.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.216.42 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org X-Rspamd-Server: rspam01 X-Rspam-User: X-Stat-Signature: 3dzso5szn3m533j6p99am3rytjjd3sjz X-Rspamd-Queue-Id: 9D884A0062 X-HE-Tag: 1662373078-195767 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On (22/09/05 22:06), Barry Song wrote: > > 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? So I didn't want to include any benchmarks, because this is entirely specific to device's data sets/patterns. In term of CPU usage, zstd decompression is really fast [1]; and the way plan to use is battery aware - e.g. when low on battery do not recompress at all, if AC is plugged in then recompress more aggressively, etc. In term of benchmarks... a copy paste from our internal tests. But *do note* that this is relative only to our specific data sets. Your millage may vary. ZSTD recomp algorithm (5.10 kernel, so the last column is the number of 'zram huge pages'): - Initial state of zram swap partition localhost ~ # cat /sys/block/zram0/mm_stat 8955662336 2180671776 2277711872 0 3179720704 798724 469474 118949 - Recompress HUGE objects only localhost ~ # echo huge > /sys/block/zram0/recompress localhost ~ # cat /sys/block/zram0/mm_stat 8944390144 2106998658 2211835904 0 3179720704 798617 469474 66821 - Recompress IDLE pages that are >= 3000 bytes in size localhost ~ # echo 3000 > /sys/block/zram0/recompress localhost ~ # cat /sys/block/zram0/mm_stat 8934166528 2085232505 2207690752 0 3179720704 798484 469474 66811 - Recompress the remaining IDLE pages that are >= 2000 bytes in size localhost ~ # echo 2000 > /sys/block/zram0/recompress localhost ~ # cat /sys/block/zram0/mm_stat 8913981440 1946488434 2145157120 0 3179720704 798130 469474 66498 - Recompress the remaining IDLE pages that are >= 1000 bytes in size localhost ~ # echo 1000 > /sys/block/zram0/recompress localhost ~ # cat /sys/block/zram0/mm_stat 8905592832 1711533182 1984495616 0 3179720704 797162 469474 66222 [1] https://facebook.github.io/zstd/