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 4741CC4332F for ; Tue, 15 Nov 2022 23:23:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 826F06B0071; Tue, 15 Nov 2022 18:23:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7D74E6B0072; Tue, 15 Nov 2022 18:23:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 677E28E0001; Tue, 15 Nov 2022 18:23:40 -0500 (EST) 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 552AE6B0071 for ; Tue, 15 Nov 2022 18:23:40 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 2A15A410A2 for ; Tue, 15 Nov 2022 23:23:40 +0000 (UTC) X-FDA: 80137255800.23.82F5395 Received: from mail-pg1-f179.google.com (mail-pg1-f179.google.com [209.85.215.179]) by imf06.hostedemail.com (Postfix) with ESMTP id C4BB4180004 for ; Tue, 15 Nov 2022 23:23:39 +0000 (UTC) Received: by mail-pg1-f179.google.com with SMTP id r18so14997702pgr.12 for ; Tue, 15 Nov 2022 15:23:39 -0800 (PST) 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=KeFCzvbHxCMk5+FnFozTy4bW8T8EDfkdgl/UWLzqnP0=; b=E7upmvckNneLUJ5t5ce/SSEpXNc6jC5Q/95UYsU5By7kT1h6pCfMkpfC8PMv1R+qHM itjzlwuAa4YLgGwb6BTLgTFRA3d0lEsvTzlQt3ZhAVHHpkMb9G6aN4o571289K/Hpm7K 5oknw92j5qvRDQrFMOiJBw7XmIdpE26u5YTMkXgXRCG0riKZwBXFsGlTzcKezrnPGKH9 nTfaXKNERLS6WbjJvkcy9ToP3qW7YvwLl/L0IT+s6M+l79gq7dN/Q6kigtLB3u3PivVf lyR/zjvK/YIl7Ac4vGLtKANJL8DNhPYqLaJwwYP9/A37evqMyhbrX1WqPpfShgN6sha7 0EpA== 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=KeFCzvbHxCMk5+FnFozTy4bW8T8EDfkdgl/UWLzqnP0=; b=HHPNnr4B1nR4s+qqoceVbc45YiPLJOTDWdy5epzL23/F6Z8wV3tlRmXyTBs6seHvhm f8oBJjIcFkAoyLTdga4TRSDvcI1sfh/BC/ZKVn7p68filylCiHepWac7jfErXWZcGY1v pL8l7cFLzBjHn0zY7LZCBWit53p+DORGTCov+Gx9YrZfCmsEUTm7Wj+eq2HdW5i/Iil1 Ij8YsWEJdZHCM56TRLNLabScp4/KZZiBSs4FxJC0t5va8cFSAY0nw4r/rGP7nqUIgJTW 3OhVsABomU5I5rmngnocM+GFURbK7zDA5oCgeac8NOEjV3sMLVHvx2czVE35xkSKW3R5 hYCw== X-Gm-Message-State: ANoB5pmH7XsGSD0uYs5F9sKjooBMTvOJL6XCwbUoa1IHqjiNERnEFMct BNUvAlkBg79+Y1xSUPbCf3U= X-Google-Smtp-Source: AA0mqf4rU0AfEIfJ+7/6nukd+YOE7yNVYuMIpXlKPRu0R12NQwcNfs1g00Jh6i0yd04CxC6k8MEVXg== X-Received: by 2002:aa7:91cf:0:b0:56e:64c8:f222 with SMTP id z15-20020aa791cf000000b0056e64c8f222mr20619863pfa.71.1668554618505; Tue, 15 Nov 2022 15:23:38 -0800 (PST) Received: from google.com ([2620:15c:211:201:6ff2:4caf:5d97:1932]) by smtp.gmail.com with ESMTPSA id z9-20020a17090a66c900b0021358bd24b9sm110266pjl.21.2022.11.15.15.23.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Nov 2022 15:23:37 -0800 (PST) Date: Tue, 15 Nov 2022 15:23:35 -0800 From: Minchan Kim To: Sergey Senozhatsky Cc: 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=1668554619; a=rsa-sha256; cv=none; b=Xts3oPj2IcwH2G77Iz8QgaeH0SSiAs8WPtbcscIbMsX6zxpc+rMILV4a15WtSmOHOvfQ8N ogVbYeR/rFxroyDuMj0wBW53nvDyUNs35zXzhkndMhi8bvsWN1rMVfAxYrU+elJO2VRT6O ra4Vdh6I7VQKVm4RpXAG84BjZNWs9P8= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=E7upmvck; spf=pass (imf06.hostedemail.com: domain of minchan.kim@gmail.com designates 209.85.215.179 as permitted sender) smtp.mailfrom=minchan.kim@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668554619; 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=KeFCzvbHxCMk5+FnFozTy4bW8T8EDfkdgl/UWLzqnP0=; b=M/krvX7q0tV/GZW4A/JGceLwxoPzWT0TGftG6hVgmjZjpL87+k6NnuSmTQLZ+RPmtqNjfW ZFUtHt7dR7cYQlpz/NS5kalUQ8b7deDtruIfQDAFqV9WFOt1CsQdwaVHZ7CEsozJF4TYpK fPFIq0/qXsOPVzT9nNJQdTxTkEJrd9w= X-Stat-Signature: 4ux3cnha4j9hsykz8jisfn3pueua95ka X-Rspamd-Queue-Id: C4BB4180004 Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=E7upmvck; spf=pass (imf06.hostedemail.com: domain of minchan.kim@gmail.com designates 209.85.215.179 as permitted sender) smtp.mailfrom=minchan.kim@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) X-Rspamd-Server: rspam04 X-Rspam-User: X-HE-Tag: 1668554619-616179 X-Bogosity: Ham, tests=bogofilter, spamicity=0.245722, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Nov 15, 2022 at 04:59:29PM +0900, Sergey Senozhatsky wrote: > On (22/11/15 15:01), Sergey Senozhatsky wrote: > > On (22/11/11 09:03), Minchan Kim wrote: > > [..] > > > for class in classes: > > > wasted_bytes += class->pages_per_zspage * PAGE_SIZE - an object size > > > > > > with *aggressive zpage compaction*. Now, we are relying on shrinker > > > (it might be already enough) to trigger but we could change the policy > > > wasted memory in the class size crossed a threshold > > > > Compaction does something good only when we can release zspage in the > > end. Otherwise we just hold the global pool->lock (assuming that we > > land zsmalloc writeback series) and simply move objects around zspages. > > So ability to limit zspage chain size still can be valuable, on another > > level, as a measure to reduce dependency on compaction success. > > > > We may be can make compaction slightly more successful. For instance, > > if we would start move objects not only within zspages of the same size > > class, but, for example, move objects to class size + X (upper size > > classes). As an example, when all zspages in class are almost full, > > but class size + 1 has almost empty pages. In other words sort of as > > is those classes had been merged. (virtual merge). Single pool->look > > would be handy for it. > > What I'm trying to say here is that "aggressiveness of compaction" > probably should be measured not by compaction frequency, but by overall > cost of compaction operations. > > Aggressive frequency of compaction doesn't help us much if the state of > the pool doesn't change significantly between compactions. E.g. if we do > 10 compaction calls, then only the first one potentially compacts some > zspages, the remaining ones don't do anything. > > Cost of compaction operations is a measure of how hard compaction tries. > Does it move object to neighbouring classes and so on? May be we can do > something here. > > But then the question is - how do we control that we don't drain battery > too fast? And perhaps some other questions too. > 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.