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 38E3EC4332F for ; Fri, 4 Nov 2022 17:27:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 942E68E0001; Fri, 4 Nov 2022 13:27:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8F29A6B0073; Fri, 4 Nov 2022 13:27:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 793E28E0001; Fri, 4 Nov 2022 13:27:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 6B0816B0071 for ; Fri, 4 Nov 2022 13:27:31 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 1E61D1C5BEC for ; Fri, 4 Nov 2022 17:27:31 +0000 (UTC) X-FDA: 80096441502.12.4409C1C Received: from mail-pj1-f48.google.com (mail-pj1-f48.google.com [209.85.216.48]) by imf08.hostedemail.com (Postfix) with ESMTP id 8D3BD160003 for ; Fri, 4 Nov 2022 17:27:30 +0000 (UTC) Received: by mail-pj1-f48.google.com with SMTP id h14so5081565pjv.4 for ; Fri, 04 Nov 2022 10:27:30 -0700 (PDT) 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=ic558+CyRUCz1e5KjxZoWOQyUv1PrJmNJRwEzMieMgQ=; b=QaPPqo8O7+x7YAkMZM+CntItXhoDS2obnuRv7W4QbTPSpfCONmNpO9DXsD07vc1DLk eT+GcU/6B3tQFCusNwuGLes+roUu+ZmM6xrrf15Zwt2cY/SvPtQOMJr0lBA0DQxywer5 Gywc8K2TqqbfLpw3FQaqxPaU+0AivMNAuRkV7bFsysDhZVgX64MTU4hfXohXukcoSZ4V NiT85BhSp1zs2/N0UugqTTFsxJbt721SIDYuoxv4x4i03K1RHUvdDdQ0nV/s6P8lKp2h mi4Y3on5DGxxH622kbZIVWZDcqf/I5AS4WAsAjfXA6NbYVpbG09glA8lE1ipeWEPyk9e 3Teg== 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=ic558+CyRUCz1e5KjxZoWOQyUv1PrJmNJRwEzMieMgQ=; b=t3gnqqXAiarFkirCNiTA/xrxmjEYyYWcexq17653NAOCM7iojS3IRU5/RUOn1EY6EF 3ULqkM6FhpFXC60raB2t8AKUYkE9SMEZSNsoDlGFqsJPFpkGsF7yXBhiZToLVXiA4ImK ykXIxt1SXdhFTwq14Ylkkwwz7d95UM5BxHbZ3NMQTTGt36PBa8EfP45m8c2lSA9yYUL5 CTNfbaiMu6hKtlfJFW2H0NzTKD/e55Z8u7jtzL9zRQhRjOTO8HWylznwrc7/yfj3lQSw HF0i3D5fp7NZpLEl6oG+vRLWTa7GqhAtZX4Nzz9ciU+EM1oNOobQeFFrivSqMT46fhdQ mUiA== X-Gm-Message-State: ACrzQf3r1Sk1x4QHvwppR6882lAjHWpKYoNnjzPgsrZ6ufqPmva2RCim tprsHcFFPxYnpH/ZMUQlIWmao3lxGZE= X-Google-Smtp-Source: AMsMyM4ySUTdCIvPYgu8hzeyqE9Nlw0BmDBEw0F+NyEkXkNLeXxgqXBOz67dZ6RscY3mcc8Dn+4wDw== X-Received: by 2002:a17:903:40ce:b0:188:62b9:cece with SMTP id t14-20020a17090340ce00b0018862b9cecemr5389069pld.93.1667582849289; Fri, 04 Nov 2022 10:27:29 -0700 (PDT) Received: from google.com ([2620:15c:211:201:755f:cdcb:1bd8:5ad8]) by smtp.gmail.com with ESMTPSA id e9-20020a170902784900b00183e2a96414sm23393pln.121.2022.11.04.10.27.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Nov 2022 10:27:28 -0700 (PDT) Date: Fri, 4 Nov 2022 10:27:27 -0700 From: Minchan Kim To: Sergey Senozhatsky Cc: Andrew Morton , Nitin Gupta , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCHv4 4/9] zram: Introduce recompress sysfs knob Message-ID: References: <20221018045533.2396670-1-senozhatsky@chromium.org> <20221018045533.2396670-5-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=1667582850; 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=ic558+CyRUCz1e5KjxZoWOQyUv1PrJmNJRwEzMieMgQ=; b=nCgIIPxwZLGvf65uVk8LVessE1qdNS+CWnIacgPOyJp/pSQsFZ9FeJtlWOF933XrHlmy3D iY7GzSZ7yCWY00UVU4XhHL+c17jYMebAfauulbA91v0+J/2X7GMAs46B7N2SS76E2seNgu fc74qb4CwTZQFGRSyW5SEISdBTf1ZfA= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=QaPPqo8O; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf08.hostedemail.com: domain of minchan.kim@gmail.com designates 209.85.216.48 as permitted sender) smtp.mailfrom=minchan.kim@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667582850; a=rsa-sha256; cv=none; b=FI5WJnkbbWLxbYTLx+ZS7fTrgpmeS5Kh2dOas/W/brsSOYszSUV8Yg3lPqZ5Qx1jlThiOq kNWOGmbxU0s8uEfp33soRe8c5eGk6paoP/qgvXt7YFKVyFGlBOObRR5BEfcMimBB2Ans/K LadPqc5eojnAXGd7Vq1dI3Qpo70aHSg= Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=QaPPqo8O; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf08.hostedemail.com: domain of minchan.kim@gmail.com designates 209.85.216.48 as permitted sender) smtp.mailfrom=minchan.kim@gmail.com X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 8D3BD160003 X-Stat-Signature: 9uzbfu77s9x8ezdg39ash5m8zqo6jmui X-HE-Tag: 1667582850-516756 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 Fri, Nov 04, 2022 at 12:48:42PM +0900, Sergey Senozhatsky wrote: > On (22/11/03 10:00), Minchan Kim wrote: > [..] > > > Per-my understanding this threshold can change quite often, > > > depending on memory pressure and so on. So we may force > > > user-space to issues more syscalls, without any gain in > > > simplicity. > > > > Sorry, didn't understand your point. Let me clarify my idea. > > If we have separate knob for recompress thresh hold, we could > > work like this. > > > > # recompress any compressed pages which is greater than 888 bytes. > > echo 888 > /sys/block/zram0/recompress_threshold > > > > # try to compress any pages greather than threshold with following > > # algorithm. > > > > echo "type=lzo priority=1" > /sys/block/zram0/recompress_algo > > echo "type=zstd priority=2" > /sys/block/zram0/recompress_algo > > echo "type=deflate priority=3" > /sys/block/zram0/recompress_algo > > OK. We can always add more sysfs knobs and make threshold a global > per-device value. > > I think I prefer the approach when threshold is part of the current > recompress context, not something derived form another context. That > is, when all values (page type, threshold, possibly algorithm index) > are submitted by user-space for this particular recompression > > echo "type=huge threshold=3000 ..." > recompress > > If threshold is a global value that is applied to all recompress calls > then how does user-space say no-threshold? For instance, when it wants > to recompress only huge pages. It probably still needs to supply something > like threshold=0. So my personal preference for now - keep threshold > as a context dependent value. > > Another thing that I like about threshold= being context dependent > is that then we don't need to protect recompression against concurrent > global threshold modifications with lock and so on. It keeps things > simpler. Sure. Let's go with per-algo threshold. > > [..] > > > > Let's squeeze the comp algo index into meta area since we have > > > > some rooms for the bits. Then can we could remove the specific > > > > recomp two flags? > > > > > > What is meta area? > > > > zram->table[index].flags > > > > If we squeeze the algorithm index, we could work like this > > without ZRAM_RECOMP_SKIP. > > We still need ZRAM_RECOMP_SKIP. Recompression may fail to compress > object further: sometimes we can get recompressed object that is larger > than the original one, sometimes of the same size, sometimes of a smaller > size but still belonging to the same size class, which doesn't save us > any memory. Without ZRAM_RECOMP_SKIP we will continue re-compressing Indeed. > objects that are in-compressible (in a way that saves us memory in > zsmalloc) by any of the ZRAM's algorithms. > > > read_block_state > > zram_algo_idx(zram, index) > 0 ? 'r' : '.'); > > > > zram_read_from_zpool > > if (zram_algo_idx(zram, idx) != 0) > > idx = 1; > > As an idea, maybe we can store everything re-compression related > in a dedicated meta field? SKIP flag, algorithm ID, etc. > > We don't have too many bits left in ->flags on 32-bit systems. We > currently probably need at least 3 bits - one for RECOMP_SKIP and at > least 2 for algorithm ID. 2 bits for algorithm ID put us into situation > that we can have only 00, 01, 10, 11 as IDs, that is maximum 3 recompress > algorithms: 00 is the primary one and the rest are alternative ones. > Maximum 3 re-compression algorithms sounds like a reasonable max value to > me. Yeah, maybe we can use flags bits for it. If possbile, let's go with those three bits into flags since we could factor them out into dedicated field, anytime later since it's not ABI.