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 726CDC433FE for ; Thu, 3 Nov 2022 05:36:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9006A8E0002; Thu, 3 Nov 2022 01:36:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8AFAB8E0001; Thu, 3 Nov 2022 01:36:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 79EF28E0002; Thu, 3 Nov 2022 01:36:22 -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 6B2438E0001 for ; Thu, 3 Nov 2022 01:36:22 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 3EA0A1A0288 for ; Thu, 3 Nov 2022 05:36:22 +0000 (UTC) X-FDA: 80091020604.09.C273150 Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com [209.85.216.53]) by imf25.hostedemail.com (Postfix) with ESMTP id D201CA0003 for ; Thu, 3 Nov 2022 05:36:20 +0000 (UTC) Received: by mail-pj1-f53.google.com with SMTP id b1-20020a17090a7ac100b00213fde52d49so849531pjl.3 for ; Wed, 02 Nov 2022 22:36:20 -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=/TkBkjczRfZq8WoQictHOaJZqwEYcHjIcgO1EkCulpQ=; b=Ct9g/wbHSd6jH86y5M4rjY+HV8ZYBWZY2MDXcvaIzSU7i8gBMzeEKGFuf1o0TK3Oel 6EONZBV+w78KynxvAAJXIEmPhGK1xZ4v1kDvd7R4iQts0i+cOh9i/NHSbuB0+2cyifhk oOXO0pdRz0JsTYDyZM9KTH03RMUXIY9fVGhCk= 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=/TkBkjczRfZq8WoQictHOaJZqwEYcHjIcgO1EkCulpQ=; b=nFTVWqt7j1Y6zUq8F3LgwQlPnD/9hcH2a9HKLBHE/s1ZrCyymlcY0dyajfw1b/bFEq e/plK18fm9bTGOSF+ljzXpGYvlw/LF4aVgLdE0fi3Y+eKlImh0hn5UBSTaF1AFxrEAyj dGEYsJYDKs3ZNj50cblKZMmiD+3aslSxAiurY+DMbDiBMXxwHWaS+LYHuRG4akhS3OTL 6Q74xf+JM1JnvhAIpXZnLl/vaJTXfiBgHL+cBnnmnZjc7M9L71jt9g6sEAqcpU2hXXs+ yILPO9Fq6reL8djDFoTgdkzuDLW8kFQ6bhX9s8sVMcqZSAgWaV5pwL0pv5Q+KPv6ujeo gsfw== X-Gm-Message-State: ACrzQf2gVHOtVvkZu1qDu0S8TLhq++u9qEmzrMniCHc8omu11kGZPfVc lah7g6st3lSQ8F1mQmKEgIB+fg== X-Google-Smtp-Source: AMsMyM56yrurEHq7nQ1UTZKYHgdrDmdf/FnazbWByIy3sbseemuEzBNuUV+DrLEXBXixtHA9u90/zw== X-Received: by 2002:a17:90a:f001:b0:213:bf4:ee29 with SMTP id bt1-20020a17090af00100b002130bf4ee29mr45918167pjb.98.1667453779755; Wed, 02 Nov 2022 22:36:19 -0700 (PDT) Received: from google.com ([240f:75:7537:3187:f22:e30:374d:5a2b]) by smtp.gmail.com with ESMTPSA id n16-20020a635910000000b0046f6d7dcd1dsm8468215pgb.25.2022.11.02.22.36.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Nov 2022 22:36:19 -0700 (PDT) Date: Thu, 3 Nov 2022 14:36:15 +0900 From: Sergey Senozhatsky To: Minchan Kim Cc: Andrew Morton , Nitin Gupta , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Sergey Senozhatsky 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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667453780; 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=/TkBkjczRfZq8WoQictHOaJZqwEYcHjIcgO1EkCulpQ=; b=sDk4hlfD0C7WGq5Jj0K2l14RHd9g7DUipwEQ5DYh1SjXr0kt4OVTea+NtKjMgPiyDDKugm OFMBkdrh7Nh2GA8yDljt40+TLepJ65ptTvMCTdETYZXFqzeie1lASQNXkRIkDDBU7igpu2 P1E67TgYcObkz73f35pd8sVSaY5FAa0= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="Ct9g/wbH"; spf=pass (imf25.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.216.53 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667453780; a=rsa-sha256; cv=none; b=pJ6JsCvAayuSNPh6y35ZIY2CUEc2Hi7CV9S8qn2iHdfpdxf/xaRzTYWQ+dOML/Txdx8bGP Y8XTjAPfMBmwuVJmpUxSqyLCVHBGv0myzFPk5jom6ZDFrD+mNHaZ4jsF+sM5rbFKjy0O77 GwhsQK3oKJDbF2eeO5QUfMSj/R26RtM= Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="Ct9g/wbH"; spf=pass (imf25.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.216.53 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org X-Stat-Signature: pneq77r5ow9fdmt77ms4u96agxf5y6qe X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: D201CA0003 X-HE-Tag: 1667453780-787026 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/11/03 13:09), Sergey Senozhatsky wrote: > On (22/11/03 12:05), Sergey Senozhatsky wrote: > > What is the use case for removal of a secondary algorithm? > > > > > My point is that we don't need to implement it atm but makes the > > > interface to open the possibility for future extension. > > > > > > What do you think? > > > > So, as far as I understand, we don't have reason to add remove_recomp_algo > > right now. And existing recomp_algo does not enforce any particular format, > > it can be extended. Right now we accept "$name" but can do something like > > "$name:$priority". > > Or with keywords: > > name=STRING priority=INT > > and the only legal priority for now is 1. E.g. recomp_algorithm support for algorithms name= and optional integer priority=. I sort of like the recomp_algorithm name so far, but we can change it. --- diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c index cf9d3474b80c..9a614253de07 100644 --- a/drivers/block/zram/zram_drv.c +++ b/drivers/block/zram/zram_drv.c @@ -1102,9 +1102,38 @@ static ssize_t recomp_algorithm_store(struct device *dev, size_t len) { struct zram *zram = dev_to_zram(dev); + int prio = ZRAM_SECONDARY_ZCOMP; + char *args, *param, *val; + char *alg = NULL; int ret; - ret = __comp_algorithm_store(zram, ZRAM_SECONDARY_ZCOMP, buf); + args = skip_spaces(buf); + while (*args) { + args = next_arg(args, ¶m, &val); + + if (!*val) + return -EINVAL; + + if (!strcmp(param, "name")) { + alg = val; + continue; + } + + if (!strcmp(param, "priority")) { + ret = kstrtoint(val, 10, &prio); + if (ret) + return ret; + continue; + } + } + + if (!alg) + return -EINVAL; + + if (prio < ZRAM_SECONDARY_ZCOMP || prio >= ZRAM_MAX_ZCOMPS) + return -EINVAL; + + ret = __comp_algorithm_store(zram, prio, alg); return ret ? ret : len; } #endif