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 9175EC678D4 for ; Fri, 3 Mar 2023 01:06:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CE2576B0074; Thu, 2 Mar 2023 20:06:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C92626B0075; Thu, 2 Mar 2023 20:06:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B5B8F6B0078; Thu, 2 Mar 2023 20:06:51 -0500 (EST) 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 A5BE16B0074 for ; Thu, 2 Mar 2023 20:06:51 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 662F2C0F66 for ; Fri, 3 Mar 2023 01:06:51 +0000 (UTC) X-FDA: 80525797422.28.0BB6EC1 Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) by imf20.hostedemail.com (Postfix) with ESMTP id 86AE71C0003 for ; Fri, 3 Mar 2023 01:06:49 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=FFoM7AZf; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf20.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.216.42 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=1677805609; 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=EwwXsWMJrnirAh+/Y2JC4tS8+2STW/C39tOpLj/kUk8=; b=1IhoaLs78omHYsTOLudGnpIpgcUqs0h4/GPJvcvBzdcIbRkxG0eV/GuQ+qVfokLEJMNV4a JoQRjjOJgMzawfXVw9WhqWzTRNXpOuSnDjGstJjemrDkn4wS9gM5RCxaLn1/3coERpKUHk z0lOfK8t4dZE0UAB/jFtC5LYXChY6Xs= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=FFoM7AZf; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf20.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.216.42 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677805609; a=rsa-sha256; cv=none; b=ckJn5FxITCSAVNRwFz2Vzf0128J+QYcRSj6J7Mr0Pnbb2mhTyfZrewxyt9cREmGfHcMlD5 IorKLR6Xx+w8FHXoV1Nafmkmjbds+IW5hLhyz2Mz1wyP7MvbqRgb3V+cG3xIWFwYxGWcMo 7PzQ68lyDsKwh5shDYBLJimenlnlRJU= Received: by mail-pj1-f42.google.com with SMTP id bo22so946110pjb.4 for ; Thu, 02 Mar 2023 17:06:49 -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=EwwXsWMJrnirAh+/Y2JC4tS8+2STW/C39tOpLj/kUk8=; b=FFoM7AZffas7rYnHcuBVGhC6QQzJaz41qkhKHUGlQyaZWY8FZ0UWf2mvf+e+nLJp5S 1+193lnt6XrZtaGiE6ydZGkvAjzd6+S4dXUJIayf9SrrpELU1+/Eq9vViRfpcmHwM9Wz uCCJvwB5IZWP1O5VGhDYzHeDeJ48mULJR8CRs= 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=EwwXsWMJrnirAh+/Y2JC4tS8+2STW/C39tOpLj/kUk8=; b=opLYN77vix+HfBGan7prRIcbe+sy9Vwb9cNQZtFZR6ijV1BQPZ+k/gqifdoLxS+UH/ r09YV4F4oLta7Tvw8zimi5CALmnlNGvyQf8a1O614gJgqu63vReCSDwd+SvGMnwUB9Tj PTQq9WyCFGTDDskf7ZvKWG8wPIcCtfuRKj8ecIrUi5O1S65J8X0lnHRmev4KXywvZLyW kf4uhPFMQB2pz6m07BaUfS0p/eG/k6EBHGXOYHuX16zTLJBI4kNgUAYb/Rgkejt6UCs0 aZarupTX85fmMlnI/t9qJmyreQgWw7lM1LvyQW8vCEYOu/jFZee8fkG6Ft3Vd1fi1iIH ntEQ== X-Gm-Message-State: AO0yUKVcP18WwSqRUEq+1BfA3qd6T3naVNGjngK5D0uJSphz014o9/Oo L8+J26NS66p2jYjsiFPPcX/9vQ== X-Google-Smtp-Source: AK7set8SRihRZc46G0YoZTU/j4Ue/C0DSlTqqvPMGPRayXqA+AtQLj4M95qxwZ0ZXyEktQnMFJxA2A== X-Received: by 2002:a05:6a20:8c0f:b0:bc:f336:98ed with SMTP id j15-20020a056a208c0f00b000bcf33698edmr307252pzh.45.1677805608072; Thu, 02 Mar 2023 17:06:48 -0800 (PST) Received: from google.com (KD124209188001.ppp-bb.dion.ne.jp. [124.209.188.1]) by smtp.gmail.com with ESMTPSA id x24-20020aa793b8000000b00593adee79efsm307077pff.55.2023.03.02.17.06.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Mar 2023 17:06:47 -0800 (PST) Date: Fri, 3 Mar 2023 10:06:43 +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: <20230303010643.GA4022757@google.com> 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-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 86AE71C0003 X-Stat-Signature: 9toanb9fodq587xsonqp8xdkardnzysj X-HE-Tag: 1677805609-514101 X-HE-Meta: U2FsdGVkX19LUuCWT37ZCtgdEgDbC9jSr1d945s03Nk3d0DYnhLb/qxDeArCjtmmnPKYBLH6w6O148yCrHXUXYmwtXJYNwQdRc2KBanNicLiH6carV3oU1siv57JptgtwK+/s2nL0Ey47tauAC0yXo34Jg9CSYLIwA7Aum95OUPNK5Cvby0FciRiEDMhF7QhEBK12Zl1qu2V6W54sRXtEkM6viNNvR59T6K4tRvBTkGQZ04xmZPgETdiENrb4BCZAaFfbFsJ6O7dTyV9qNugwGL65fbDV52yaHBZLfDXp5PuCD/TnWXjeD+KOLEMaDr/KYnuca4qlm4lFvwS2trYDnosBTnLZSNRLZVocE3cOdrSuQNERKK57JPmJIrdFe+1gqnSqFnU8viHpFk/KBH4ywTjpplzzSbkdy9Bttbka4St+lf+eoO01uJAEWzFM8I8mUcZIopCHjUzpWdS1GDlatTnVU34IHJua1Eh7vFAa5RXyeymSeRf/CPy5Bcf0kBWLWSTDpkEUfbMo0EmXg4kwguUEkz7jzws+K4dK9O3LmzPjGCrFPRX6Qun6eSJTIxds7vPfIKSXX2iI2SHZKWxPXR2LWB21sr7hI1hEULIfPDJIj5TRAe9YX7hI4YtJvNXj+CDI6KZNrVkuiYjvC0yv2sA/tcUN6EXNbGx7lBDOe26RoNrHOYxzi3LkHcAXUHHY3YdhHoy7mj1+gGtwh3REYtfWdatrfiVLRzlus/jNGtZGU+B4eXRA2pgLeZ26sljeSa46rwUO7AqmS+gqt9wTy6eliP89Dj+5IKUUJ/4MSIMi0YAs+DHQp6GEwdas6j4VZQVRPpx5fTVt/jVprk6aYIwQ7HtuAXltRn4lwT+yfnKWRzXIDWmtMEXli4eQo3usFRxdAP3UowqEL6mnb1oei0sQghs93xnIy4HbClnZy6T0g3tElHDQZr4PKwLVe8ns7OqIXWwatUydLf1DJU kcW9vj78 vDptzaRoThER21CGXxo6isPScX4S3iojDfttbmvEKBulJq9OLfMaA4kBERsIkdP2fuTy2gWWF75iT3olTHmqh6zUgPGxlBmkIygWOnmtfSKZMdgW8DRxWLsfolDqyuzlb1Kb3go77YWmG6zUPgtym9QdAQ2fEZ9pFnBUchx0+ZeyQLtPJT5C9NVaql7eDM5HvmahXz+20WASzCQHVvgar85eYR6UJfc6CbeU19ykc//BHyb0/xHn6/hUiz7v/8SAiI60i46QJ+KGfhI0TYbpcLRJzTR87wPqaGLdswr45JDGBfOvkr5NovQysec5pYWei2J6S1uWlKj3H0bw= X-Bogosity: Ham, tests=bogofilter, spamicity=0.205874, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On (23/03/02 16:20), Minchan Kim wrote: > On Thu, Mar 02, 2023 at 09:53:03AM +0900, Sergey Senozhatsky wrote: > > On (23/03/01 16:28), Minchan Kim wrote: > > > On Wed, Mar 01, 2023 at 05:55:44PM +0900, Sergey Senozhatsky wrote: > > > > On (23/02/28 14:53), Minchan Kim wrote: > > > > > 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, > > > > > } > > > > > > > > For educational purposes, may I ask what do enums give us? We > > > > always use integers - int:4 in zspage fullness, int for arrays > > > > offsets and we cast to plain integers in get/set stats. So those > > > > enums exist only at declaration point, and plain int otherwise. > > > > What are the benefits over #defines? > > > > > > Well, I just didn't like the 12 hard coded define *list* values > > > and never used other places except zs_stats_size_show since > > > > If we have two enums, then we need more lines > > > > enum fullness { > > ZS_INUSE_RATIO_0 > > ... > > ZS_INUSE_RATIO_100 > > } > > > > enum stats { > > INUSE_RATIO_0 > > ... > > INUSE_RATIO_100 > > > > // the rest of stats > > } > > > > and then we use int:4 fullness value to access stats. > > Yeah. I don't see any problem unless I miss your point. OK. How about having one enum? E.g. "zs_flags" or something which will contain all our constants? Otherwise I can create two big enums for fullness and stats. What's your preference on inuse_0 and inuse_100 naming? Do we keep unified naming or should it be INUSE_MIN/INUSE_MAX or EMPTY/FULL? > > For per inuse ratio zs_stats_size_show() we need to access stats > > individually: > > > > inuse10, inuse20, inuse30, ... inuse99 > > Does it need specific index in the enum list? If we report per inuse group then yes: sprintf("... %lu %lu ..... %lu %lu ...\n", ... get_stat(ZS_INUSE_RATIO_10), get_stat(ZS_INUSE_RATIO_20), get_stat(ZS_INUSE_RATIO_30), ... get_stat(ZS_INUSE_RATIO_99), ...);