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 CF9E8ECAAD3 for ; Mon, 5 Sep 2022 21:27:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 45FEE8022A; Mon, 5 Sep 2022 17:27:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3E88480224; Mon, 5 Sep 2022 17:27:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 261D38022A; Mon, 5 Sep 2022 17:27:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 0FE6B80224 for ; Mon, 5 Sep 2022 17:27:21 -0400 (EDT) Received: from smtpin31.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id D871A1602E3 for ; Mon, 5 Sep 2022 21:27:20 +0000 (UTC) X-FDA: 79879317840.31.D09466B Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) by imf04.hostedemail.com (Postfix) with ESMTP id 9B1B54006B for ; Mon, 5 Sep 2022 21:27:20 +0000 (UTC) Received: by mail-ej1-f47.google.com with SMTP id kk26so19227869ejc.11 for ; Mon, 05 Sep 2022 14:27:20 -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=pSL2MZrpVB7qxuOy9eYDodpImR+sJNN/K13mEhYsepI=; b=cowKY13aK1XRDe5igS3FPN14nBu4YDfTCGgQTEMDPH+lKsLWSRPno9GjMV/Eilzz/g 2b7ximSJT7cB0QsnYWTt5dOHKh3pE6TWIw0nTyBBh9YPpMRex/sDVrwx/A7tbDY7fXSg vuHIgQxx/dz/v+WKILO4+OAyRJC5tb/iShTNn4vL9qsFuiPf0ibckmNHHHNNtamuO6GV j710FWtjQ33Gm/yq2K+Uf+J10IQh6W1U8GtWaMjiXIonQQQJLtUvcuj3T1ImipVeUVxt 1m32ApU7cW3/qCYMibWyD4BGNpx1IO7qm/jkGdFLur3x1dJUxib5M2PSgj3FIUa6I43D SZBA== 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=pSL2MZrpVB7qxuOy9eYDodpImR+sJNN/K13mEhYsepI=; b=je04Y2T/hmdDfevHFsRYsTFjNatINZoxZa41fIU2BrroKKuSXTxJMWsr1TV/qV7SoE RxnDwEN2nZZ2KNNLZn4e3FYnooe0f8Qqa8Qa4xQfmyKpyUW/Hn08LEvag/s76iNSL/Hx QXOtF0+5C7YYVC6OlQgeQgBiXaD4A374UmirEtNju9n+wncnebYWLw9ZoaMShXX/SkL0 gIpjrQf/zY4CPjQORzd7puX9EK0OLexsUNwhwdGNwZXpy/ZkCDjUm4NUVlMXEuOf/Tnw aVPO70B1FgqPmZqw7kvXfQvnDvMdJGnESdr7RjnEgzaV7khur5Rm38khJSkLqjAOjPNG XZmg== X-Gm-Message-State: ACgBeo2bPO7Y7z1tdc4kbLGTd3moGTK4TAeMtbDL7jEKbP+71uA9UXY4 cKB8v//0frxjTlKMNNG+gocbpU3wi8slz6pNcEE= X-Google-Smtp-Source: AA6agR7keC7o1LaBA6FdPEjezVKDG9tZsO9ABOeeccUYRet74YeiohD0rMsIAEc0SrBZzVgX29S+r9c1Wc64MWYVfto= X-Received: by 2002:a17:906:8b81:b0:733:183b:988e with SMTP id nr1-20020a1709068b8100b00733183b988emr36582320ejc.457.1662413239154; Mon, 05 Sep 2022 14:27:19 -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: Tue, 6 Sep 2022 09:27:08 +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-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=cowKY13a; spf=pass (imf04.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.218.47 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662413240; a=rsa-sha256; cv=none; b=unIZOUZzjiQqm8EuerIzlVcL6GflNvoLR6AGKMleoXZDQI5nfW54DXWmoUGp/+FyRunN2h v8VGEhJ/mnTxvAEqwJ5/NQtwwAWI4wctLGS6a2F7htpHJIoeMsl9Pd8d1DyHnIxT/r1nCU IXkVA8ZSyBdgzybLIIx/jtnZKcM/IZs= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662413240; 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=pSL2MZrpVB7qxuOy9eYDodpImR+sJNN/K13mEhYsepI=; b=ynAJ8rWXI5cHui9wKaq0P8+2Q20yykMaX6JQZO/RUisbGaDgGTWZTmmkwP0SMQHTxdCO7v 2knfc49fq/X/IqqAAsIJhrbfCb4dW6YXLRonMSuqLxpO7b2kuyixSriYcywqyx97cYLrER nxRNvqtjf07brymHa/cim1vTrJrEIgQ= X-Rspamd-Server: rspam02 X-Rspam-User: Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=cowKY13a; spf=pass (imf04.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.218.47 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Stat-Signature: 53radz384fcwiru5mfctcroofsduqycq X-Rspamd-Queue-Id: 9B1B54006B X-HE-Tag: 1662413240-87141 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 Mon, Sep 5, 2022 at 10:17 PM Sergey Senozhatsky wrote: > > 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/ Thanks very much. I guess the difficulty is that we need to comprehensively evaluate its effect on a real product such as android. there is always a trade-off between cpu utilization and more available memory. Best Regards Barry