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 30BB8C64ED6 for ; Wed, 1 Mar 2023 04:05:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9A1A66B0095; Tue, 28 Feb 2023 23:05:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 950A56B0096; Tue, 28 Feb 2023 23:05:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 818176B0098; Tue, 28 Feb 2023 23:05:29 -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 722496B0095 for ; Tue, 28 Feb 2023 23:05:29 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 2DB651607F2 for ; Wed, 1 Mar 2023 04:05:29 +0000 (UTC) X-FDA: 80518989978.08.DC515D4 Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) by imf28.hostedemail.com (Postfix) with ESMTP id 57482C0011 for ; Wed, 1 Mar 2023 04:05:27 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=HR8GKavd; spf=pass (imf28.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.214.171 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677643527; 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=2FPGRrE+V/xFQnOXY47Z4N5HYXwwKgdZ1V3Mwf45FFw=; b=Lx36KCdKoHYRU+6iMSNWl+rwKPUoF9hg86Sf5DR3IAl3obGDHw5nvaQbgcY2Dm0QrGGgDg KVw2kJLgtIuHsNJE4mEDDU7re7a8Eo9Gov4M30crF+8vp2l9nd/k3xDwKdJL9Z35wLTp2T nCbFrzStif7q4EIYp1bXH7hzSkWQdK8= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=HR8GKavd; spf=pass (imf28.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.214.171 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=1677643527; a=rsa-sha256; cv=none; b=zKh8btyHsfRWepCmvRHEwVlvKxZSp++rH5wuP/Eud70eZyq+16qDy7ORfJ0bP3l7zM+lbo L7EdgWcyD6uOCaiZBW8gBYoY8EvaHLdvUmLy6JUEWlslJQLbwoOadoAyut+ovhyuyhs160 CIL0iORXBVq0lsD4GbHZCBD7n87RoBo= Received: by mail-pl1-f171.google.com with SMTP id p6so11845225plf.0 for ; Tue, 28 Feb 2023 20:05:27 -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=2FPGRrE+V/xFQnOXY47Z4N5HYXwwKgdZ1V3Mwf45FFw=; b=HR8GKavdpOywG5msuZfmCzJY8trT5TMtz0JxwK42GoYzZQ3BRSdh95NC9MZ2Gs6dB9 /8/Bi8h70aBOVv9tPJSASYflzLWjCiHcWLY6jrCTO9qBD72/Xe+r3ell0M3PkCyqYpPS 9hdXYMXaGYn5liN+yf6qKoaW4obLlwtHRZfCA= 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=2FPGRrE+V/xFQnOXY47Z4N5HYXwwKgdZ1V3Mwf45FFw=; b=PHkSqdfPInttt3/xm+N+inH17+GuAF6pSoSFXD/KOqFn/YY2+CMFxrCW3MtjlJZmsy YC30b946oEdRmQe+N/4rGQTvkVDmSC69H/2A2k36p4LIdSpHZlWOzlQOoS8mNTaKMwAb aIFzQIt6h/AplRtJ8Dae+av8zb+UZENWeVOJKyqAJ0BrGsaxs2VJPKkAOr3hQU8mCO+Y 2QBAQsE9kIkttavhzUeBh4W8+vUcgL6DP3OaO5IY+JvshQ5FgOpPqEr5O3UmZ40wskH8 X+i1e8GMFwGzru93p0C5AFPrB6xs81UEDViSdivt0hXOgG5zeK+L5UDoLjB3ENrof7rk qmoA== X-Gm-Message-State: AO0yUKU/VOFXqTJCA763AiyfiUbhbhSPlbdwaHhkwWz3fQPZj4Sm/yMD GG7VPvb9v3FXMnsijOA4g1HaTw== X-Google-Smtp-Source: AK7set8UDDWK+HqQf3vdr+m6xpSpUGiLi5vsnrM+tZBNDX0NwjF7KAiTN2QnAELwgMYpevySd0uRWg== X-Received: by 2002:a17:902:74c4:b0:19d:1bc8:4889 with SMTP id f4-20020a17090274c400b0019d1bc84889mr4422404plt.57.1677643524679; Tue, 28 Feb 2023 20:05:24 -0800 (PST) Received: from google.com (KD124209188001.ppp-bb.dion.ne.jp. [124.209.188.1]) by smtp.gmail.com with ESMTPSA id l17-20020a170902eb1100b001992fc0a8eesm7269787plb.174.2023.02.28.20.05.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Feb 2023 20:05:24 -0800 (PST) Date: Wed, 1 Mar 2023 13:05:20 +0900 From: Sergey Senozhatsky To: Minchan Kim Cc: Sergey Senozhatsky , 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-Queue-Id: 57482C0011 X-Stat-Signature: hstyus8zequaqdwybj5mrjy41jdmx5hf X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1677643527-25506 X-HE-Meta: U2FsdGVkX19VNa0xAVkhMRR+hGhenWfW23jb5XOigoi48xCJc2AW49dMHtgeqIPP1SUlcqtXmyopLLO/l/ImW2b5DhaysB4A2RR5HkUit04G8SYM0+AaMdroKV4Y9tEbmWtCM5rnTJ+1rzv2+I5J8FqjmLuj+PIHoaDd33Y/1aacBlIeXWO7HmpLHBEAIEA+NSH4wjd8pkyeZm6jcEMj2cLZm+4T64B2TYK37yuCC9OUcP3fl8btmO/9GRUP11/pDxh1kNcYlCMckdSv4TitTmRLrOO2TPuuSAX1vq1uucbKFNH30GN7+a2poNP9SRWnuX5Li37xp/oLTuBWqfjEHwsHGD1gQO1IIVMCvlGX0ikYAODxCpvI+WZFRy8hL7DU0tcv33mUFkYWl55rFLEnyuVipTGCMwDixPaFlxiiYozG6fVBzX78mnbHyy7o+yWrkylqswmj9le0lEL89LoKfo3kDaGkwe3yEh8gM81tpKlHuGB3trIapzStbDk+VDE+iSss0lFQgQWPui5B+ILjjRRbjnSTQY9qY5CKTLtlANL98Pq8C/K15Z9jNt5yY9iDnXKwxU5Y/clDPO41L1KC4Pk+iX7GfVa7VIW82iCpchW3xpZ4IihGK0imR1woQWRZXOfTyj9u1lDk2GHVfjSl+9foEKXV+/ilU0w3g6aA61d6YI8sWfq1LgEOfogIOI+TFySiUcxVkn43ldJZ3THpD2oFIJTdb942BOZ1099EWpnv01CykaJzRsmutt0SH3hgF4yrfv7/+QZi/KKIYUQU2BliG/2P4ZaTqwedMShtZPOOHpcXr+KdHB6qdF99W3NaIAY55O20uzYnObGYEgVzmwwnzox03bCp8wBMAPvZbwWrJUhfXL8ZfgVkWUT0IbZGpoiUxJLFVVrkZnVaaJnsyzBUqGvStSKlUn/BtrP7ssyiJR1iNgACHm/0WhVBJYhuQVFcVO7MRCW/Py5tVcc TlqsSvkl Vx9dLd8fa9+/Y/5N9z2tgl7P2becACeKYB174vAfkMra7t2R6lFGUDfYgG+I8Zmr+UO7PmxeUFlhWKMfkL8o5z0Y0HQk3f9wuzffOpUR6xT/ihD4v0TakLlumPkuhs9QqxX/mKwlK0fOxsjoZG9zoL71ozMRRUZ1rAV4rYgRyPTtug2gXQ6RnO4GyzlaJ5kHxy0ZnxNyQ6OUH6fhKL64LDrd4zgyanBtKAdRFYOHssBWalnUghEO3EJl0THLxDhNN/LrLvPilVoMCVbEZzTuqXXQ/vB2YHjdH+p2qb7LUdsv3+B6p1swyBoPgooZr/jW7wl2UKYsZV/MIMZo= X-Bogosity: Ham, tests=bogofilter, spamicity=0.018257, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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. 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.