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 0AAE9C67871 for ; Tue, 25 Oct 2022 01:53:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 693C280008; Mon, 24 Oct 2022 21:53:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 61CBC80007; Mon, 24 Oct 2022 21:53:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4BDE180008; Mon, 24 Oct 2022 21:53:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 3993380007 for ; Mon, 24 Oct 2022 21:53:47 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 0051EA0549 for ; Tue, 25 Oct 2022 01:53:46 +0000 (UTC) X-FDA: 80057800452.03.145C018 Received: from mail-pf1-f180.google.com (mail-pf1-f180.google.com [209.85.210.180]) by imf27.hostedemail.com (Postfix) with ESMTP id 784774000A for ; Tue, 25 Oct 2022 01:53:46 +0000 (UTC) Received: by mail-pf1-f180.google.com with SMTP id y1so10557456pfr.3 for ; Mon, 24 Oct 2022 18:53:46 -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=SxEDdrI3hG+3w7IQNJoTP680/J7pecyDNQ+fXuXkvxc=; b=lvthVIgC1NtFIR4sPKrIoZwiG9zP5R6DWNjRaGZ7js6qWVwfYYYLxW5Vha+2T/Tu40 srgZ1HmT934KOevMHcaVYnL45zY870tJhTlsKSoiPTvdk9RA3ObqBiD3zbev7oAnkPFc U5tjB7IzZBU3Pu98pZJX+7vrpVW2LrMihQDT0= 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=SxEDdrI3hG+3w7IQNJoTP680/J7pecyDNQ+fXuXkvxc=; b=tjtLcb+FljZ/XvlSD2ykQ3ToplGNwtbAseuM/rpF1ZjGgnCf0Js979GVtkbc97sLTo c1/Lyg8L3iVO8DhRK90Iw6RVM1u2xgaTOsnBGfqVXSVPs4CcYfNkJPg6QZIXMydhEnOl 8flaJqaSFgTHrbztiVwdiC4Q40Nmeu2IdNbb02UAlecywqRqe9uefk+YKkXv8gOBP9uf vofWLt7xd806bpd3bakieVwIBCi2SROFfsNUVb+aPKhGt62KXJhscD39uo6ZEO5kwpyT 9oAw4JBzpauHUYjiZJ9qRHTXmLgbW3q+gfxnCW2BqQvEcxfPb56+DE8JfT289yevBMww x1ig== X-Gm-Message-State: ACrzQf3/psSvYfao5X6OLZNNQo1zNIuOoFi0HPbcXQ1YVw5IQBZbhR71 cJ8lLIBXzb78BwwsfKTh4Lhk5A== X-Google-Smtp-Source: AMsMyM6Vv3O1q9mWvI+nbcBXaj0JCZ/oPUmPNvPTwSWJ2ZRat2qEgAB1QrCGVz9afYd9QX9Fe2yakQ== X-Received: by 2002:a63:a509:0:b0:46e:e85f:fb8 with SMTP id n9-20020a63a509000000b0046ee85f0fb8mr11346959pgf.519.1666662825385; Mon, 24 Oct 2022 18:53:45 -0700 (PDT) Received: from google.com ([240f:75:7537:3187:c493:65a6:2d64:1325]) by smtp.gmail.com with ESMTPSA id z11-20020a17090a8b8b00b0020aaa678098sm453963pjn.49.2022.10.24.18.53.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Oct 2022 18:53:44 -0700 (PDT) Date: Tue, 25 Oct 2022 10:53:40 +0900 From: Sergey Senozhatsky To: Alexey Romanov Cc: minchan@kernel.org, senozhatsky@chromium.org, ngupta@vflare.org, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel@sberdevices.ru Subject: Re: [PATCH v1] zram: add size class equals check into recompression Message-ID: References: <20221024120942.13885-1-avromanov@sberdevices.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221024120942.13885-1-avromanov@sberdevices.ru> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666662826; a=rsa-sha256; cv=none; b=GOynISVL/2e7cjFGsaTsWZINu/VuRAI2Chr8k+fi94mJMO3pSHbuVC3j6RHk5Y5rFHqEIO J8bsNEhTo0HKNMfWxrhUb7rp3kQU8kPzgrl8lJxNlVD53mhl7Gyka9In/jGymatFplOOtm Y+faJzqTblXYLSsfEXx4AV0g75mG+a0= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=lvthVIgC; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf27.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.210.180 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=1666662826; 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=SxEDdrI3hG+3w7IQNJoTP680/J7pecyDNQ+fXuXkvxc=; b=VL7QZyk7xjnMt3pFRkBr82sbqmkcuuxVlGG4+aXWVW6hnRQQTndYexCY0kvu1hu9a5+QOz dnaiC+OfyUaAV7O/NzJOUNmbv8qYjEbx+89oFeqQhkmPsizNFS9ebW/RDWBL3inROwvu6l 4T72GK7nFMAcs5aBvTC0zTyBaYl9Nww= X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 784774000A X-Rspam-User: Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=lvthVIgC; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf27.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.210.180 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org X-Stat-Signature: q9pd3fnipmfumwg8hga39swzkkj3fqqo X-HE-Tag: 1666662826-622941 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/10/24 15:09), Alexey Romanov wrote: > It makes no sense for us to recompress the object if it will > be in the same size class. We anyway don't get any memory gain. > But, at the same time, we get a CPU time overhead when inserting > this object into zspage and decompressing it afterwards. Sounds reasonable. In my synthetic recompression test I saw only 5 objects that landed in the same class after recompression; but this, as always, depends on data patterns and compression algorithms being used. [..] > + class_size_prev = zs_get_class_size(zram->mem_pool, comp_len_prev); > + class_size_next = zs_get_class_size(zram->mem_pool, comp_len_next); > /* > * Either a compression error or we failed to compressed the object > * in a way that will save us memory. Mark the object so that we > @@ -1663,6 +1667,7 @@ static int zram_recompress(struct zram *zram, u32 index, struct page *page, > */ > if (comp_len_next >= huge_class_size || > comp_len_next >= comp_len_prev || > + class_size_next == class_size_prev || Let's use >= here, what Andrew has suggested. > ret) { > zram_set_flag(zram, index, ZRAM_RECOMP_SKIP); > zram_clear_flag(zram, index, ZRAM_IDLE); > diff --git a/include/linux/zsmalloc.h b/include/linux/zsmalloc.h > index 2a430e713ce5..75dcbafd5f36 100644 > --- a/include/linux/zsmalloc.h > +++ b/include/linux/zsmalloc.h > @@ -56,4 +56,6 @@ unsigned long zs_get_total_pages(struct zs_pool *pool); > unsigned long zs_compact(struct zs_pool *pool); [..] > +/** > + * zs_get_class_size() - Returns the size (in bytes) of the > + * zsmalloc &size_class into which the object with specified > + * size will be inserted or already inserted. > + * > + * @pool: zsmalloc pool to use > + * > + * Context: Any context. > + * > + * Return: the size (in bytes) of the zsmalloc &size_class into which > + * the object with specified size will be inserted. > + */ Can't think of a btter way of doing it. On one hand we probably don't want to expose the object size to class size mapping outside of zsmalloc, but on the other hand we sort of already do so: zs_huge_class_size(). > +unsigned int zs_get_class_size(struct zs_pool *pool, unsigned int size) > +{ > + struct size_class *class = pool->size_class[get_size_class_index(size)]; > + > + return class->size; > +} > +EXPORT_SYMBOL_GPL(zs_get_class_size); I'll kindly ask for v2. This conflicts with configurable zspage order patch set which I posted last night. get_size_class_index() now takes the pool parameter.