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 D6FCBC678D4 for ; Thu, 2 Mar 2023 00:13:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 516FE6B0071; Wed, 1 Mar 2023 19:13:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4C77D6B0073; Wed, 1 Mar 2023 19:13:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 38E896B0074; Wed, 1 Mar 2023 19:13:27 -0500 (EST) 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 26B706B0071 for ; Wed, 1 Mar 2023 19:13:27 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id DA951C0B32 for ; Thu, 2 Mar 2023 00:13:26 +0000 (UTC) X-FDA: 80522034012.21.CFFFF1D Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) by imf03.hostedemail.com (Postfix) with ESMTP id 0E05B2000F for ; Thu, 2 Mar 2023 00:13:24 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=mqUy9BFb; spf=pass (imf03.hostedemail.com: domain of minchan.kim@gmail.com designates 209.85.214.172 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=1677716005; 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=0hnX+HdIFXVPvQ22LkGsYX5Bz0blCWB2FI4mBtVnh64=; b=mPvOIUePYT33O3NDBZI2kkBb8BT98/qKswt8E8lVymBP1TSdWRtjmMBTtLod/QvCZbJoUv YDA7841MG3rxwtVqIZTVALVBy6mMajlua1PS8VZvafmS4f3ud4zhTU4tUy1AQU3iCNSJDn GGXg4lt01uxGs2Fml8Kz/st8PKae31o= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=mqUy9BFb; spf=pass (imf03.hostedemail.com: domain of minchan.kim@gmail.com designates 209.85.214.172 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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677716005; a=rsa-sha256; cv=none; b=yjK1X3QyGxNRMeLU/BlNKgS2b3UqggToetBwaycuGVrwiSXMu4MnPIsydEJxc5vw5SkTfQ iTHJuzNycQurUwCfsHyOVQMKMB2OKHEOLGCdJrDoXvPPwvhYq8CjAtUXG4/fbBoMroOUA2 pbEV5L79++uFOZcMvbcMr4fA/tCdcrQ= Received: by mail-pl1-f172.google.com with SMTP id i3so15843733plg.6 for ; Wed, 01 Mar 2023 16:13:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677716004; 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=0hnX+HdIFXVPvQ22LkGsYX5Bz0blCWB2FI4mBtVnh64=; b=mqUy9BFbn5pRWO3F4oA9v7oqc9ngHvcaayGbpRYNfzivE8FgEbes8epuR1+CcQpRdK SDvhsM9QKwOURjzE18GBiuNZOAF2YGyupCDFp4Z/TaU2vA+d3M4hWZ2tK7AWKVOmT8zV gNw4L9AZC0HEf3g4kK/ti7OYtJGyFIRciy6Pb92ZzVFjKhakZwSUqJm6Ne/iepTlLvUf /w5QmayhRJJL64+ZmUw7cuT9TnzYyizvK5cX+arbIq12cTf6M1MUisW2rIWyKa2n3tQj 1ni9SBjCopSKLwjVbmEobW/JRLgVFOZppaM8/79c1Siff85R3yianlMuNRQP34rSUiOy eMCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677716004; 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=0hnX+HdIFXVPvQ22LkGsYX5Bz0blCWB2FI4mBtVnh64=; b=l6z2GmLxlGQNhVo8WuIx9vm2qx+enVU5ENpsBANbFigX9krEAfIhVbDixnDjblhCQU ahAofRHA41LR02S18OHVXtNDn51Lbc3CzZRrb7w6oRs6SmTKjQKgDqvHlINi9m04JURz 8hAfkNx5QfAImnyWYDSVQ46S3u/dpry3VsV9oaOrkSuxQSV2NLeOIQwqV6fGQgjEzE3D sqYOOQLBUAZq7QqPYF4WRw5rY4gQ6IPJsahAF+9kZJdV9IvVLp5Li1+D0JWOG7kb10At W5kYrdErBRqTYUmTKHGgGCqeZrJ0LpfOqEMR7YUeZkAhodGfqGG5svlhZFgfee+dITFJ D96A== X-Gm-Message-State: AO0yUKU2Nl35xTYZ4vxmMKd82CIHlNNBAiBqAlG2rcBNEGKUjvYYU9h4 YaEXF/rHDu+ibYbs3B9NKsQ+II0H3x4= X-Google-Smtp-Source: AK7set/i+/8BY4tBNHAMPtYzDDlfogiQzHzSxE0LqP/t5YYwwiivr4mZ17nciB33TaPGzSuxnFcjog== X-Received: by 2002:a17:902:d48e:b0:19a:a520:b1fc with SMTP id c14-20020a170902d48e00b0019aa520b1fcmr303047plg.14.1677716003802; Wed, 01 Mar 2023 16:13:23 -0800 (PST) Received: from google.com ([2620:15c:211:201:a524:71b8:ce7e:745d]) by smtp.gmail.com with ESMTPSA id 1-20020a170902c24100b0019a8468cbe7sm8521160plg.224.2023.03.01.16.13.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Mar 2023 16:13:23 -0800 (PST) Date: Wed, 1 Mar 2023 16:13:21 -0800 From: Minchan Kim To: Sergey Senozhatsky Cc: Andrew Morton , Yosry Ahmed , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCHv2 3/6] zsmalloc: fine-grained inuse ratio based fullness grouping Message-ID: References: <20230223030451.543162-1-senozhatsky@chromium.org> <20230223030451.543162-4-senozhatsky@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 0E05B2000F X-Stat-Signature: okm847kwju4wb1sqbzyquach45dj7hof X-Rspam-User: X-HE-Tag: 1677716004-634875 X-HE-Meta: U2FsdGVkX1+pCdcp/IF8E7d9vCvh05/snh8zVkbxCAfyL54quhXQKxl309Xzj0zZbd27coMTw1w/ixaVXGm6ifwWc34uNHpQQA3hvqkg6POheLfbUkM4WQF9iQYoWtnZeslhCXV4NmfLpa6YZgZsXlNzKRruqCtHN9aO5IfGEAGp+WaC5c2bLxpcXg1wWAesObbHmARPgbaL0mCYeKcDoJDFIjIH2K2JhZ5JPnucLcwDFAI8RSqsx9JJVJjmsLtvH3JiNLbIy2NhRJPHCP/gPVqOoehAT3jWRnAR+DV2HO84ik5eOOZiHwXVgN5J6lLpVz+ixEPieGOxsCslQXis1owTkTowYjwN3KtXEaeSa6KXxbH8d4o+aq9HH+LPQVUFp3WAZ24U/rw3vcJnypMAAObFbmpgpqhWwOGYUiqhPCyjUBzIvb0u2nNet5RVr/wvtWWlFzidYJWBBCBO2xe3MWQ7yDo+ZTb69w9sDduMQxG/KTLWzS/3qwhhj0C3oY/NLLYKqOGZym4bttt6QNNKmM2poga5D85YIUvgJO26B32nFVpGMbfbN9eRn/yVmrs7PiVmB9U1Xyk59G2OZN10gaBw7i831gPTxK8dIbmR/4wRS+o0dzhXKtbBnfbzyfy8QDWZ1yBkOgX6ZrzClWV6vyGfJR+4k+C0SfpU+0CE5jhPmnY7w1m95yaa0LA3WnzFgbf3s4bZFUMej/9GOMlbwb8wVnsmPni89v2tW4+aVADfZUl5WTF95oca1AlfMqL54qnsXY7/iSC4GK3p/6/wB3XcTAFsl88JjeNiRr39dhrRR5AkPZMN3iI18sP+d83VjW0BpOSiD3neX7Ae3f39D2+rZrZO0MOFslkjFxIviUxkxSPf35GJIvSKOOijZmgtthZEsmCPbrEum9DgR6IP9Uy5h6V9Sq2M08NhoRKX5o6cIXdArwGHvlvrEV9bWAkC48a+GxJpdXo9GG+mfth xM12ldp2 WAJP3z8C/YyERYcsl7p+2SbZ02pR4C1vC2Gz3blyTsyI/yMzlmtuNjqs8f1KYO13QQLHX8aUMlYtPvsKCPstd/ppaHNE6vBowLyblcPZB38XrNHf9fo2+eWuSrlvzvc0nF7W4fdMfjNxnhU/fbXdIdsJYBatgWH+FiYf5XwC4FisSsMbnzNB40WJ9Jw25Vl1/KZ9Sc/DPlPLPju/at8hDVSTBAdDx6/5niD06Tg+GNA94fgjV0s+gQBh8S2mXQ0D7Pbv1LWITVYUdf7XPVRiZHSHlkffGZQFQbfamWErTMbjFSzbE8ywuYhN0DquCyEpbH/Sq8TfKgURZHg2I2xk0KuwdPjLDpx35KelPIiQfLr8XblmPk6Z9yE5tEVRDiQG1jR+XnukMhsu+jvtxSAbb8aFHLggjGpMhMLFQLypj6VV5lalaOdLfzDlBIIo0iMyttwgQLZF6BwGDpV8Q1mcDTH8dU0uADPEFHuaCOQaYErjLmDEn1FPaJEusRWyINqBT6jxSo5lgSfmZ8kboY7X9uqYNUhWUuHoG3szUWKgulgJLPQg= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000004, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Mar 01, 2023 at 01:05:20PM +0900, Sergey Senozhatsky wrote: > On (23/02/28 14:53), Minchan Kim wrote: > [..] > > > As of why I decided to go with defines, this is because zspage fullness > > > values and class stats are two conceptually different things, they don't > > > really fit in one single enum, unless enum's name is "zs_constants". > > > What do you think? > > > > Agree. We don't need to combine them, then. > > BTW, I still prefer the enum instead of 10 define. > > > > enum fullness_group { > > ZS_EMPTY, > > ZS_INUSE_RATIO_MIN, > > ZS_INUSE_RATIO_ALMOST_FULL = 7, > > ZS_INUSE_RATIO_MAX = 10, > > ZS_FULL, > > NR_ZS_FULLNESS, > > } > > So we keep enum nesting? Sorry, I'm not exactly following. Sorry, I meant let's keep separating them since they are different things conceptually as you mentioned. > > We have fullness values (which we use independently) and stats array > which has overlapping offsets with fullness values. > > [..] > > > I can change it to > > > > > > for (r = ZS_INUSE_RATIO_10; r <= ZS_INUSE_RATIO_70; r++) > > > and > > > for (r = ZS_INUSE_RATIO_80; r <= ZS_INUSE_RATIO_99; r++) > > > > > > which would be safer than using hard-coded numbers. > > > > I didn't mean to have hard code either but just wanted to show > > the intention to use the loop. > > Got it. I just wanted to show that being very verbose (having every > constant documented) is nice :) > > > > > > > Shall we actually instead report per inuse ratio stats instead? I sort > > > of don't see too many reasons to keep that below/above 3/4 thing. > > > > Oh, yeah. Since it's debugfs, we would get excuse to break. > > This was in my original patch, but I decided to put a comment and keep > the old behavior. I probably will switch to a more precise reporting > (per inuse ratio) in a separate patch, so that we can easily revert it > without any impact on new fullness grouping. Sounds good.