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 97C0FC433FE for ; Tue, 15 Nov 2022 07:59:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E68646B0071; Tue, 15 Nov 2022 02:59:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E17AE6B0072; Tue, 15 Nov 2022 02:59:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CDF726B0073; Tue, 15 Nov 2022 02:59:35 -0500 (EST) 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 BCC5A6B0071 for ; Tue, 15 Nov 2022 02:59:35 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 71702409E6 for ; Tue, 15 Nov 2022 07:59:35 +0000 (UTC) X-FDA: 80134927110.09.E7BB26B Received: from mail-pg1-f182.google.com (mail-pg1-f182.google.com [209.85.215.182]) by imf29.hostedemail.com (Postfix) with ESMTP id 10C6A120011 for ; Tue, 15 Nov 2022 07:59:34 +0000 (UTC) Received: by mail-pg1-f182.google.com with SMTP id o13so12573616pgu.7 for ; Mon, 14 Nov 2022 23:59:34 -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=DdOHxmLLhGQ2JS9VW3BK8nUHmYD6rCy1tiLuitS/qc8=; b=VyVL1Bz+AZz4KIISx7l8OK+u+Ne9T1mg0PrhTLKUq57AoS4ltny4XHyWDRP3srrYg7 7+LrXDAXXa/jJY17NUc5skWgpLqYxy/9dcfQHAyZ7oCojp92eWJ+IXXaHyLw9euzjgcQ B6NRNt+i2c3fkrwebxYTbTRmh6NxZLpK/Hoho= 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=DdOHxmLLhGQ2JS9VW3BK8nUHmYD6rCy1tiLuitS/qc8=; b=c7GSMlQLbwKyue1vesZqy/gtgtaLd987s6s1buayT39R0xnFGS0nxxs2HyV/XZnOh6 dq3rj09niAJpwvq1HpgLbzC6mej/lPHaJlzmltaOAwX3qRnrTHbx6mtpdRg+JoiQUsMQ hF8gFIU3w0uZJoxTMq1Y4P0oPwx+mvdXmKXClPXjxoZstthMzCQPZd6O9pF6Ou6WmGzG ICIToLIsCneb7YqaZChiRJpb6j9Tb1YVMXhTdS5e0QdE7obns5ie9iw/L8aKlirkJf2D 1zvO6i421hNFgMCXjuD1OEiUE24bDQtWgr+fE6Qv4d1+nL7BrfubB7xlHeEn4vZJUmcl puPQ== X-Gm-Message-State: ANoB5pnj7T2w9iCLYMWTMsP+nxADkrMo7DkkoqDExcC4sn6Rcw3o9O/v 9/rXMJ0Nji9lyweXy7hGWdTaTA== X-Google-Smtp-Source: AA0mqf7W2F5p+UWpTOghIiQlnL/OofJ/jf5ouCPUJe19FXfixiaZSfa48cupX1iJVLSdfMhoD67Tbg== X-Received: by 2002:a05:6a00:b49:b0:562:bcf8:7b35 with SMTP id p9-20020a056a000b4900b00562bcf87b35mr17603263pfo.52.1668499174008; Mon, 14 Nov 2022 23:59:34 -0800 (PST) Received: from google.com ([240f:75:7537:3187:3d10:c2ca:ba5b:55e6]) by smtp.gmail.com with ESMTPSA id i187-20020a6287c4000000b0056262811c5fsm8052909pfe.59.2022.11.14.23.59.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Nov 2022 23:59:33 -0800 (PST) Date: Tue, 15 Nov 2022 16:59:29 +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-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=VyVL1Bz+; spf=pass (imf29.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.215.182 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=1668499175; a=rsa-sha256; cv=none; b=gxceFSgw3l1zk1yuZlWTao9nD2pUa+SX8raPJaitosGD1RPSV9u4icq3hKfqLX48xQex9E w55Co7kYPjgfvDSaZzcJaq/GbUTrA/Q6JYnbJF4DfLK+KFofp0i62P75yD/OG4KVAAzDG+ rORufUOU3DM8A3GqEsxaGqoIm3JErx0= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668499175; 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=DdOHxmLLhGQ2JS9VW3BK8nUHmYD6rCy1tiLuitS/qc8=; b=LdMdumt1DrAxMdmYxU/PpaLPpmFKtOES3quXSxw1NMaLeeokVh1xabAfnxktBGa1A0PnOd KQMiCa6uUBHCeycYu06Gq0Jxk0dFGN4N2CI7zV463F2PUkZnZtwFacMs8atov6FRUMq8pY tP2pTb1CH3Jsn4Tu/Nn9cdxovcghmss= X-Rspam-User: Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=VyVL1Bz+; spf=pass (imf29.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.215.182 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org X-Stat-Signature: w1zj531i5nsuerkekuwg9c1r4uucrh7z X-Rspamd-Queue-Id: 10C6A120011 X-Rspamd-Server: rspam09 X-HE-Tag: 1668499174-20549 X-Bogosity: Ham, tests=bogofilter, spamicity=0.106037, 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: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.