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 DB814C433FE for ; Sat, 5 Nov 2022 00:00:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4242D6B0071; Fri, 4 Nov 2022 20:00:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3D42C6B0073; Fri, 4 Nov 2022 20:00:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 29BA56B0074; Fri, 4 Nov 2022 20:00:40 -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 13EF56B0071 for ; Fri, 4 Nov 2022 20:00:40 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id C5D00A1306 for ; Sat, 5 Nov 2022 00:00:39 +0000 (UTC) X-FDA: 80097432198.21.4FFEC44 Received: from mail-pf1-f180.google.com (mail-pf1-f180.google.com [209.85.210.180]) by imf20.hostedemail.com (Postfix) with ESMTP id 49EA51C000A for ; Sat, 5 Nov 2022 00:00:39 +0000 (UTC) Received: by mail-pf1-f180.google.com with SMTP id b185so5821672pfb.9 for ; Fri, 04 Nov 2022 17:00:39 -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:message-id:reply-to; bh=3Bw4Wg2xM8DW6Uw0JUkLXkChOTfhtB/Y2VzKaH2aphE=; b=Bj19pyyzgXJLl9fB0xAc++0ux7QPokfwNSjJe28MuqeoYBzC87za4SQpYMPVs6NWH9 6qbO19bDDHhdDI5tvodUZL98nh9vPkArZSUuEz+jeKcn9uRUZwVzzDDHR/MbUDVDPk+t UdeRKjuAyDR7MvQyDTLESEL5GuwQxv2JaoWMg= 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=3Bw4Wg2xM8DW6Uw0JUkLXkChOTfhtB/Y2VzKaH2aphE=; b=cV0bVGJTouDb76gsW1rfwUZVCjlgFvObQck3gaxOk2IkCUdmf/GIqEiRcCvjWHt0Of sUp6rAxb0PMeCAgL37CL9YyKuFleQEJr+KwkgJeSScLoV5GDgMqtfGtaPwHCFpmiuMjx OtStBBVtRCiv/qfGSNffzbC4OpeQiScHH07y0yRwIXM/6Qc8qHMSq+mpj9w+VvQPh08d wgG+q8hQacI8jcRSknjdsd8KCSBzf0fALThg+296vVYfCLp+2N4D0YNUhYkgIyZrjcAc M4XNjpxRs+ezJKUQWECTXfs+Dk84cLOK5d7awwux6TiySctwMYkkf4K6HSMfByulICqD rbVg== X-Gm-Message-State: ACrzQf2En0Rl2IWjcU8Ae3kJQD/XKgr2LACyKbZyGX2x1WAmD6Zw8ky9 D7OJ1L39O/3rYx41eNlwvEF5pNleyNH7iA== X-Google-Smtp-Source: AMsMyM7IrcW5lKw5T6cWL2oCNHX/Rtw3BbCJE746Pii74aoaedXsJt2l1A9zNdQMpIW/N5kQYIssVg== X-Received: by 2002:a63:4d53:0:b0:470:4522:2cf1 with SMTP id n19-20020a634d53000000b0047045222cf1mr2164820pgl.32.1667606438081; Fri, 04 Nov 2022 17:00:38 -0700 (PDT) Received: from google.com ([240f:75:7537:3187:f2f6:8f5:87c8:3aeb]) by smtp.gmail.com with ESMTPSA id y12-20020a62640c000000b0056c349f5c70sm175258pfb.79.2022.11.04.17.00.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Nov 2022 17:00:37 -0700 (PDT) Date: Sat, 5 Nov 2022 09:00:33 +0900 From: Sergey Senozhatsky To: Sergey Senozhatsky Cc: Minchan Kim , Andrew Morton , Nitin Gupta , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCHv4 2/9] zram: Add recompression algorithm sysfs knob Message-ID: References: <20221018045533.2396670-1-senozhatsky@chromium.org> <20221018045533.2396670-3-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=1667606439; a=rsa-sha256; cv=none; b=I1F2mnhL17BLlDHKUGJVViBp+CttW3DEA5JunVxFWVwnQLXl3Vu4dgudV8q5W2bz1/ITG+ xgB1iRKF9dUoam/bJ+vHTSEi616oHysQcyy5UGVgdYXNX0QDS5UPJn51hDULLrOL4QdhUv JJaxyMBL0daqPVcDb2OPvxi1JaHN6Y4= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=Bj19pyyz; spf=pass (imf20.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.210.180 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=1667606439; 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=3Bw4Wg2xM8DW6Uw0JUkLXkChOTfhtB/Y2VzKaH2aphE=; b=Cg2zZc0PXb0HMeuGwfYX+JikFP2Jdbp5qgXVo7p7+xiJFvNCzkslgao+QXGUIhXFuM0GOF k4zm4Ufp7bCAbDm0DjC/GsIg4YyEWo6GfsBPq/HASZ7ADqe2TqDE3//yaC6RrDDqiR+JhP aurOQKZlX2bHx0gRthcEfJHOdqFduWI= X-Stat-Signature: wg89yd8w1pomzbqsn1tkeop1jk56hjyg X-Rspamd-Server: rspam09 X-Rspam-User: X-Rspamd-Queue-Id: 49EA51C000A Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=Bj19pyyz; spf=pass (imf20.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.210.180 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org X-HE-Tag: 1667606439-327437 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000018, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On (22/11/05 08:41), Sergey Senozhatsky wrote: > One can be SW one can be HW. So I thought about having flexibility here. > Instead of doing > > for (idx = 1; idx < MAX_IDX; idx++) { > len = zcomp_compress(zram->comps[idx]); > if (len <= threshold) > break; > } > > We would just directly use the suggested algo. > > But we probably don't need that param at all and can use > the loop instead? My idea was that recompress does not loop through the algos (what on the fly recompression can do for instance), but instead recompress only does one thing. Because we can have, for instance, something like this algo=zstd priority=1 algo=deflate priority=2 And we recompress with algo=zstd only first. Without going into the slowest, most CPU and power consuming one. If the memory pressure keeps increasing then we might do algo=deflate recompress, as the last resort before we do writeback. But we may skip algo=deflate altogether and go straight to writeback, for instance because we have less than 30% of battery left. So the reason I suggested algo= in recompress was, basically, for that for having exact control of what recompression does.