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 61861C433FE for ; Tue, 15 Nov 2022 06:01:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 60EB66B0071; Tue, 15 Nov 2022 01:01:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5BF8C6B0072; Tue, 15 Nov 2022 01:01:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 487606B0073; Tue, 15 Nov 2022 01:01:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 3A6FA6B0071 for ; Tue, 15 Nov 2022 01:01:10 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id CCCF4141036 for ; Tue, 15 Nov 2022 06:01:09 +0000 (UTC) X-FDA: 80134628658.11.96EC40E Received: from mail-pj1-f50.google.com (mail-pj1-f50.google.com [209.85.216.50]) by imf28.hostedemail.com (Postfix) with ESMTP id 5850BC000E for ; Tue, 15 Nov 2022 06:01:09 +0000 (UTC) Received: by mail-pj1-f50.google.com with SMTP id e7-20020a17090a77c700b00216928a3917so15924702pjs.4 for ; Mon, 14 Nov 2022 22:01:08 -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=Qbbp7EKV7fq9bVBmYPEt1VHCQM25Vfel3HOW3LqcouU=; b=T/9s6RfSTd+Zea5yIicxqn+IcbXtJDKYWooHtIM2M133U9T6uy5fGQ/gU00XxG5NNy AZnwPHZHESa8kaxaPhAeE/1yYc9YfFpzqtt+5lK8T58sbkt6Lp4SrqXP/5mmH9nZpx5p VdSSSYrAgP8J1VrXaOiJ7wtbif69cjo2vJqkw= 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=Qbbp7EKV7fq9bVBmYPEt1VHCQM25Vfel3HOW3LqcouU=; b=r7zpHdi4/IFIo62QeXEsbGMf2jG9U8AL66rk17IVnL+RmQ83QKptEtQhPCOL4wVUdk F8tPGg1/o5CFw9aZMjpQPP3nEpoBU92nsrLN9ebavs0mBqDZyk/UYJ4aCBg3MJaoFGXf NUdA80IvJWQcHe5QKn/xJuR9I63tpOEF4AHtbRvKkRiAVNg1E/70ffXtkvGuwoXpwFw1 z4vP4FRH8eSbBGxqhcJdi4gXC+3zmfDX3Hbgj+YNTLp5uQ5oSK2Bt5SEMfs5VwlRc98r dCAaBTBoeq/YTKMJUS6Tuz6N9IgYxHMDr+KIJF1pNTyeM2G+evLTa7gkibqujFAE/TXl rYPQ== X-Gm-Message-State: ANoB5pkchg9rNZbjGJZt4GVYxLfyiZyHzQ1HFwFaeKlSN75w4bFYWV3B zs+DkDhhFIHYOMMOeT4RMqSa1g== X-Google-Smtp-Source: AA0mqf7YHseVeZHmH48Yt2HT0XGnJz3qtTmRMwbRzNHwgU9XgL94LA/sXgK8TeM3FZTxLff286SjHA== X-Received: by 2002:a17:90a:74cf:b0:213:f398:ed51 with SMTP id p15-20020a17090a74cf00b00213f398ed51mr578813pjl.216.1668492067993; Mon, 14 Nov 2022 22:01:07 -0800 (PST) Received: from google.com ([240f:75:7537:3187:3d10:c2ca:ba5b:55e6]) by smtp.gmail.com with ESMTPSA id m15-20020a656a0f000000b0045dc85c4a5fsm6900883pgu.44.2022.11.14.22.01.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Nov 2022 22:01:07 -0800 (PST) Date: Tue, 15 Nov 2022 15:01:02 +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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668492069; 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=Qbbp7EKV7fq9bVBmYPEt1VHCQM25Vfel3HOW3LqcouU=; b=0uW/s8o4V/MpdLTSF8QHW6rtQvFlSzLPVJXNIisx+KV47RfYqybhkw1e7t9blVHUUjWz/k wFDPFwSdg905u+02kUsQOGXmFrJcmII6m0IVvyoq5mc+OKuGqN2HjKsV72Jr+2bOHH8Oq4 4OQsu0XtnkOcMV6pON8RPyue1sSC8P0= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="T/9s6RfS"; spf=pass (imf28.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.216.50 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=1668492069; a=rsa-sha256; cv=none; b=vj/8kJpg79bOuI+DGdoakPGn17/j8IGX+q+nNMcDrEJRWA0ToTzJUeA7RqLOOTvtuUOokt 6QtLDY3y1+tlE03Z/rdGAx9/zgjnbRgTAhSUbHTZv1mKYMdVf2Dcb7/OWoRqs26UziArYY eNsUT5PlMJmjdqXwTn1LJ0a+nNJWYUQ= X-Stat-Signature: n6qasc1h61xy8bkyhudikq1mdyt3fni1 X-Rspamd-Queue-Id: 5850BC000E Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="T/9s6RfS"; spf=pass (imf28.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.216.50 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org X-Rspamd-Server: rspam07 X-Rspam-User: X-HE-Tag: 1668492069-692607 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000195, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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. But this is more of a research project (intern project?), with unclear outcome and ETA. I think in the mean time we can let people start experimenting with various zspage chain sizes so that may be at some point we can arrive to a new "default" value for all zspool, higher than current 4, which has been around for many years. Can't think, at present, of a better way forward.