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 C4FC3C433FE for ; Fri, 4 Nov 2022 17:43:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 69E4D8E0001; Fri, 4 Nov 2022 13:43:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6271C6B0073; Fri, 4 Nov 2022 13:43:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4C8B68E0001; Fri, 4 Nov 2022 13:43:35 -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 3EE126B0071 for ; Fri, 4 Nov 2022 13:43:35 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 00C8B120517 for ; Fri, 4 Nov 2022 17:43:34 +0000 (UTC) X-FDA: 80096481948.23.E7561B7 Received: from mail-pg1-f171.google.com (mail-pg1-f171.google.com [209.85.215.171]) by imf03.hostedemail.com (Postfix) with ESMTP id 8E1AE20003 for ; Fri, 4 Nov 2022 17:43:34 +0000 (UTC) Received: by mail-pg1-f171.google.com with SMTP id e129so4959569pgc.9 for ; Fri, 04 Nov 2022 10:43:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=Ym4tTa7HJpk2L/lI6OldtK0o0jadOpOF8+GMFA83qbA=; b=RJ6QR4IglVEuR0hYC7lz/fpX6wgtAH99brFcbLXCLtVZxIkpLB7HbT8rXXyyHHZQ2q QzEJU9GX9LXDgR2m2KLJXrj7lJPYICrlC5QpJmzRxiVl1W2BeE7lle/rUAqcXDOEh0ra iU92VKcrwO4vjavCX8Y24xRaJe/tQXe2+qnz3+uG6JJakC+TP+qWox485vUll7I+62X5 tqK6ID6DQP0aYieT5qrKd1DXfL1ABBya6A6JJf4Wb4FM/tD2fGm7kr+5mydalyqwxfaz JQ4LlEO92wjSrYaHKpENjtykxsR1cosO0LGjA4XKCobThCjtf5kEMbVNlZsg7nL5H8xS ixyg== 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:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Ym4tTa7HJpk2L/lI6OldtK0o0jadOpOF8+GMFA83qbA=; b=eFIXKhYt+l4npPF4fBGB2zAdPtpFiKc3rM6dxUI5InPnP9Hrof8FbYOPwRzjLR/S6C D21OE/kp2GOEk8oGB0fw0Ym9UmHmuwxSTVCuDWebTUj74ayBtym6lI9mZ4GmzSW03rlb 30qZwIxwAh03gYC5ISncYBVSISsw0thlpDm2Q5hGmECP8W2f+fANk/xvwk9YCKJP0/48 Bhmj09ocqqYJcuPg9sBrZBOOs5h/QEIR5UPoY4SJ+5O5fp0oXaqVyto2ep0P0Gk2srhW PfcNWY6iAzoHYSNbTM+Tv83NAsHp7ltAF8xIRw0BkdC7yh0SguztBW3zgB+tnkrun5+3 eDyg== X-Gm-Message-State: ACrzQf3WTYbmvOOkkNikAl/YX3nZ6HKBU8w3Q7AMESXlcu43DeMLLVAf dUOVBKS//TZbGbKbb9DSffY= X-Google-Smtp-Source: AMsMyM6vVs4RHT4CU/n6Se1T6SbF1VMwI6DW/K9IjlT8qUrCcsN3/fCU/NKL0FRHGYsk270C8JCEjg== X-Received: by 2002:a63:1d0f:0:b0:46e:e211:5433 with SMTP id d15-20020a631d0f000000b0046ee2115433mr31224631pgd.324.1667583813256; Fri, 04 Nov 2022 10:43:33 -0700 (PDT) Received: from google.com ([2620:15c:211:201:755f:cdcb:1bd8:5ad8]) by smtp.gmail.com with ESMTPSA id x1-20020a633101000000b00464858cf6b0sm13848pgx.54.2022.11.04.10.43.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Nov 2022 10:43:32 -0700 (PDT) Date: Fri, 4 Nov 2022 10:43:30 -0700 From: Minchan Kim To: Sergey Senozhatsky Cc: 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=1667583814; a=rsa-sha256; cv=none; b=an5urOi0TMMVSHWZwCx8TWOGJ8Lf5F+yu44nD29zzZNChvwKLRNCWJY/CC39tdhFzpETeV 5Wdrd6oODCaN+7s5CXBonzv7cKSkRFj/KsLSo6kTLdmyx+chDLtiRGGo++Epl1lRsyIdfl /4BdqFic7f7LCQeRTTBLMbp0G7lqV7E= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=RJ6QR4Ig; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf03.hostedemail.com: domain of minchan.kim@gmail.com designates 209.85.215.171 as permitted sender) smtp.mailfrom=minchan.kim@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667583814; h=from:from:sender: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=Ym4tTa7HJpk2L/lI6OldtK0o0jadOpOF8+GMFA83qbA=; b=dEUk7RJTmwynWU52gkBjV/UOG1ESsZbZ7Hb2+1kIEh1rNYwzwknRoOsBCMH4SBzi0qu5ZI PI4yG43c4UnLyABrlHdHk6ZZAl4iMjb62p9QaQy92fv7ExhOpXsGNm4feRs+2Rx47K6dnF nX1jxtur0e5iQ8Iecdxi5CWXYFWmBss= X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 8E1AE20003 X-Rspam-User: Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=RJ6QR4Ig; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf03.hostedemail.com: domain of minchan.kim@gmail.com designates 209.85.215.171 as permitted sender) smtp.mailfrom=minchan.kim@gmail.com X-Stat-Signature: 1m3ykpwf5w3cgm19buuc7woeyooh3y1s X-HE-Tag: 1667583814-493732 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 Fri, Nov 04, 2022 at 01:53:11PM +0900, Sergey Senozhatsky wrote: > On (22/11/04 12:18), Sergey Senozhatsky wrote: > > On (22/11/03 09:34), Minchan Kim wrote: > > > Yeah, I like the name and priority format. > > > > > > Only question is how we could support algorithm selection change > > > under considering multiple secondary algorithms. > > > > So what I was thinking about, and I'm still in the mental model that > > re-compression is a user-space event, just like writeback, extension > > of recompress sysfs knob with "algo_index" (or something similar) which > > will mirror algorithm priority. > > > > Example: > > > > Configure 2 alternative algos, with priority 1 and 2 > > > > echo "name=lz4 priority=1" > recomp_algo > > echo "name=lz5 priority=2" > recomp_algo > > > > Recompress pages using algo 1 and algo 2 > > > > echo "type=huge threshold=3000 algo_idx=1" > recompress > > echo "type=idle threshold=2000 algo_idx=2" > recompress > > > > Maybe we can even pass algo name instead of idx. > > Or pass priority= so that interface that uses algorithms has the > same keyword that the interface that configures those algorithms. Hmm, why do we need algo_idx here if we already set up every fields at algorithm setup time? My understaind(assuming default(i.e., primary) algo is lzo) is echo "name=lz4 priority=1" > recomp_algo echo "name=lz5 priority=2" > recomp_algo echo "type=huge threshold=3000" > recompress It will try compress every objects which greater than 3000B with lz4 first and then lz5 if it's stillgreater or equal than 3000(or same size class). > > I still don't see many use-cases for "delete algorithm", to be honest. > ZRAM is configured by scripts in 99.99999% of cases and it is For the development time in the local side, people usually type in until they will have solid script version. If we asks resetting to zram to modify it, it's not good and consistent with other sysfs knobs we could overwrite it to change it. How about supporting overwritting to chage it over priority? echo "name=lz4 priority=1" > recomp_algo echo "name=lz5 priority=2" > recomp_algo # or I realized to change lz5 to lz7 so echo "name=lz6 priority=2" > recomp_algo > quite static once it has been configured. So we probably can use > the "don't setup algorithms that you don't need" approach, to keep > things simpler.