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 468D8C433FE for ; Wed, 16 Nov 2022 00:52:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8581B6B0071; Tue, 15 Nov 2022 19:52:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 808D76B0072; Tue, 15 Nov 2022 19:52:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6CFCB6B0073; Tue, 15 Nov 2022 19:52:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 5CC716B0071 for ; Tue, 15 Nov 2022 19:52:57 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 1C53480AB4 for ; Wed, 16 Nov 2022 00:52:57 +0000 (UTC) X-FDA: 80137480794.18.A923F0E Received: from mail-pg1-f172.google.com (mail-pg1-f172.google.com [209.85.215.172]) by imf17.hostedemail.com (Postfix) with ESMTP id AFAA640010 for ; Wed, 16 Nov 2022 00:52:56 +0000 (UTC) Received: by mail-pg1-f172.google.com with SMTP id v3so15193106pgh.4 for ; Tue, 15 Nov 2022 16:52:56 -0800 (PST) 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=xb7zxmPf+ONVcQfpx029D/sCIkvuG5jR1+Y0BJgF2PM=; b=blnaeTtTyzXnpZLcVwA0S+muYWw5gbA6AuneyeHjS5EHufk8lvDIW+5DEyky6sjS0I SOZM6SUqaeoldKZsm7NXvK7xrMyhmTNRglHT9uMqaatqMEWVXPIqhXHfU/XZiVUoimRX DxV966vq8/IKmmmH2Lzw+0wYedFI+IEpZF9ww= 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=xb7zxmPf+ONVcQfpx029D/sCIkvuG5jR1+Y0BJgF2PM=; b=DGVEl3Y23mQdYdQps5pMeiXrq1B7B9kd7SKRXZY6W8V4EXBtIT9I9vbkg7+PJH1UJ6 087fvihZyTorMC56ibbEmQTCPl/kSv/7ftr7PdIZBwdvZZbhomk/bE6AwotAQq0BxirF IMSXB+vqz0pymadWgf0OeOs2+BO1NeZI0uIePEy/jsb2ygi6sySzdpvvfKv1jSZYsMrV cizMBtdzYQRc9ASC/0Hl0GPqUZ9ykbnfRu8pxkEyWssjuVli4d95yLetoT+Pvz2kPYZT IXOivZpF1z8rlcVgkbUdjU1Ro+Jhb8sq++V6cRtKwdujcoKjZ1QYYj6rDr5WkDFKIcvJ Gr2Q== X-Gm-Message-State: ANoB5pnVhc2HCqBmt5MgkoU3MEONx1InzIuFMzHx6Hs3xXp+rQUfQtfB VohRZ6xmPxCLbyDdTztXw+Jy9A== X-Google-Smtp-Source: AA0mqf48PAGcMUFTmYQmJSHT+lbl25BuF1R+3JiN++qxnGv41DmnIxEBd4aKybk+oJEp/VKmrJvylw== X-Received: by 2002:a63:5d46:0:b0:46f:9c0b:1e86 with SMTP id o6-20020a635d46000000b0046f9c0b1e86mr17621582pgm.508.1668559975565; Tue, 15 Nov 2022 16:52:55 -0800 (PST) Received: from google.com ([240f:75:7537:3187:9603:e3e0:aec4:58d5]) by smtp.gmail.com with ESMTPSA id a11-20020aa7970b000000b00562664d5027sm9473087pfg.61.2022.11.15.16.52.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Nov 2022 16:52:54 -0800 (PST) Date: Wed, 16 Nov 2022 09:52:50 +0900 From: Sergey Senozhatsky To: Minchan Kim Cc: Sergey Senozhatsky , Andrew Morton , Nitin Gupta , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCHv4 0/9] zsmalloc/zram: configurable zspage size Message-ID: References: <20221031054108.541190-1-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=1668559976; a=rsa-sha256; cv=none; b=gRy7kF9UvLyKESk4lPglCqoma6+9Dm6JEjsl5VYawvcm/DQl90EatVwhlTIg4Xwhrd8giQ 0UKXa6I5nx8P9xtuGqxMK9KMA69snlKePXPYNFL5IUni5GZLn56VKuhE4uXKwv86yaY8fN KBva51bIclXJAxOTmpD6i9VNQdL2HrA= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=blnaeTtT; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf17.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.215.172 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668559976; 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=xb7zxmPf+ONVcQfpx029D/sCIkvuG5jR1+Y0BJgF2PM=; b=DRwbMykXDWcaOgFGXZxV2nj1Pfdry40cdjrMRQIJBmVq7rk5Oxt5eRLYMPJlksCu6cYilv mnyAeeuoq87WsdricWbdCQy0/iFPNyamesH+uWm/Y+QsRcYBStZKEctZkNzSNNUWUWNKFH r2k0j37daj2FENQW3w9UlfyCsGlejIs= Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=blnaeTtT; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf17.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.215.172 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org X-Rspam-User: X-Stat-Signature: i18i194gikkwdtfxiqeqkaos7us5kcc5 X-Rspamd-Queue-Id: AFAA640010 X-Rspamd-Server: rspam11 X-HE-Tag: 1668559976-627188 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/15 15:23), Minchan Kim wrote: > Sure, if we start talking about battery, that would have a lot of things > we need to consider not only from zram-direct but also other indirect-stuffs > caused caused by memory pressure and workload patterns. That's not what we > can control and would consume much more battery. I understand your concern > but also think sysfs per-konb can solve the issue since workload is too > dynamic even in the same swap file/fs, too. I'd like to try finding a > sweet spot in general. If it's too hard to have, then, we need to introduce > the knob with reasonable guideline how we could find it. > > Let me try to see the data under Android workload how much just increase > the ZS_MAX_PAGES_PER_ZSPAGE blindly will change the data. I don't want to push for sysfs knob. What I like about sysfs knob vs KConfig is that sysfs is opt-in. We can ask folks to try things out, people will know what to look at and they will keep an eye on metrics, then they come back to us. So we can sit down, look at the numbers and draw some conclusions. KConfig is not opt-in. It'll happen for everyone, as a policy, transparently and then we rely on a) people tracking metrics that they were not asked to track b) people noticing changes (positive or negative) in metrics that they don't keep an eye on c) people figuring out that change in metrics is related to zsmalloc Kconfig (and that's a very non-obvious conclusion) d) people reaching out to us That's way too much to rely on. Chances are we will never hear back. I understand that you don't like sysfs, and it's not the best thing probably, but KConfig is not better. I like the opt-in nature of sysfs - if you change it then you know what you are doing.