Received: by 2002:a05:6358:111d:b0:dc:6189:e246 with SMTP id f29csp1005138rwi; Wed, 2 Nov 2022 22:54:46 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6iYL8Rhar4pbZPSMK3ck+9OkuHhwXiFgMXsvqfdSM6AL3Xxzw5z/f76oHyUkbIO+rIKp2v X-Received: by 2002:a17:907:320c:b0:741:1e55:7a69 with SMTP id xg12-20020a170907320c00b007411e557a69mr27968812ejb.740.1667454886468; Wed, 02 Nov 2022 22:54:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1667454886; cv=none; d=google.com; s=arc-20160816; b=mJDbnXPI/9FEQKcH6oy5TOhWx//0Jdq0rJF27SNpz7tuorFqdW+CWw08pJZ9Np1Kim o/79D1QM4e1D3mMBkBqVh7HMtj97Q6AAAV21B2XbVB1nGgQoZ9WnFz66Tq9TxKFiaHuk 3546v+phxKONk6soCOfL5sKjrsgBLoqnqmhlYEHYRfawKVZ0nmHkWYiyrXJT7eQALhdx rjY1Bs8jlIVYFGjuIu0/JqeUSeC0Hlt44NMCjWn1HrZW3iIPM05lrHezJLPq56ffHXsz vO4SXLQKJXGcMf+Y5RgDeO7lihkY8W2hYHLFWdV8nySwQlL+7YKAX8UoNu0cOT4k/Ure HIAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=/TkBkjczRfZq8WoQictHOaJZqwEYcHjIcgO1EkCulpQ=; b=qieJR11utNF/qjKiwlYBQBcTcv3772m4/aKdEmSCDhlSOm3Y15N4Lrovu2UEigMChm Bw85FpbOajnioyzlL98TSiLY4Rfe2EciSSXaM0a3wURm1OeUm0z79yWBhpYvt9sr/H9F RMtk++xfgcKuzz+BOkp6cv9Nd52FJhCXGyth7NLRZSetZrFy19geItWAHBWmu+jnu8cx jze6YLlhBxgtoQaaQdVw861fwA4vHc0yWhOyGJvaSYQcivQZOUJxZTLVErkvCc8KC2WO p3MJC7oXArvTcg3zt7SrjDcBSBlhNoe3JjqQDH9+YaeN25XFL8sp6qI905m6kUXfnhEt QysQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b="Ct9g/wbH"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id dr22-20020a170907721600b007adf9d2fa0fsi58705ejc.947.2022.11.02.22.54.23; Wed, 02 Nov 2022 22:54:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b="Ct9g/wbH"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230182AbiKCFgW (ORCPT + 98 others); Thu, 3 Nov 2022 01:36:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59274 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229436AbiKCFgU (ORCPT ); Thu, 3 Nov 2022 01:36:20 -0400 Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 320A71109 for ; Wed, 2 Nov 2022 22:36:20 -0700 (PDT) Received: by mail-pj1-x102e.google.com with SMTP id d13-20020a17090a3b0d00b00213519dfe4aso861378pjc.2 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=lMgiYJ2f7po+3ps+6oNct6Bg0np0pgzU9tQdnIwEXbnXUTGUJFh+KmcX4R2RUCgB2o VKBakUM579Qmh63Ab1MFmUaXgQ0gIWhmGqpxRH5cYhr/FyPHJO4EDZvF09XvQXsSR5j2 IxoEcLLnE3DGuiOB64s9GMloNR8NsRROb2LSDUw6oKCTlt6OneL663s/8cerSVujZ+7C EvLjlhSLztEQ74WtS/0Vm4NqEcy59eR1+0NQFWpczFGyUpXanp/54pVTI1gZRsTUNMb3 AfSYnkc7fNNd2Hsnq4o2SfXeZKzkRgaKxBCVBkStry/vUNweB4LSXSILBJ8c58unuihM OEqQ== X-Gm-Message-State: ACrzQf0EvP7KHvwptQYaGUSsAZhfsrns0grQh9in47quymYYNhOzvfAS SkgODgSxbssCcBJX7KrahUxsmV9vhqnGVA== 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: X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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