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 87CBEC4332F for ; Fri, 11 Nov 2022 10:38:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 075C26B0071; Fri, 11 Nov 2022 05:38:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 025ED8E0001; Fri, 11 Nov 2022 05:38:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E2FB96B0074; Fri, 11 Nov 2022 05:38:16 -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 D16C46B0071 for ; Fri, 11 Nov 2022 05:38:16 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 99CCF1C6040 for ; Fri, 11 Nov 2022 10:38:16 +0000 (UTC) X-FDA: 80120811792.30.0B75D34 Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) by imf14.hostedemail.com (Postfix) with ESMTP id 3307510000E for ; Fri, 11 Nov 2022 10:38:16 +0000 (UTC) Received: by mail-pl1-f182.google.com with SMTP id k7so3936110pll.6 for ; Fri, 11 Nov 2022 02:38:15 -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=WDAe46mocv8N19iUrpVAVRFXORmPxnlQIO/wxgYUTno=; b=FrAUhA4rAeuVcuLA/U9mmmOErKic7EKby5f9WqhnY49RBIBvSl6wi0k9EsT2MWpAsf Y/mPpF4p1/2+X5nBq580SGeo7HCGsnKW9FTZXlhybSKLv5m8EByjVlbEXJQEbO3Mi2d8 rdiVUha2xJT+zYkfMj9qsT/cOiSRC5pTJAjVc= 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=WDAe46mocv8N19iUrpVAVRFXORmPxnlQIO/wxgYUTno=; b=a6KqVth3O3UphBgG9qqbPzlAqqWujcx3mGZSIiEhTQ2dL+oUQGp5hR92OHetkZfzh5 AytQXPUG6d21WgNYj7uG8/FUmZlHiWC1UzR5u1PdC5VRDX6JgKhkPQmeNWnjqPS0WNIJ C0G1Xv+fmPAVKFuY6/AxDfPPMnL51HwRsmBo44P7D+tzP26Kj80renJl8jkkNnV0f4kj xz0l9jLp5MdlXx8c0t9xcsdlx+nNL55BBqE6ocyqaO+iaz5G4krgrBLB5dFni8k2bQXL x8ORQ0mjuUpUyw73uzpd4UgxcY2tm8KFBn0M4AM5EUnwQIepOpiEUlo7rhZTMMboai0b 1zXQ== X-Gm-Message-State: ANoB5pk5GWMXqHpjmJgK3v9xoa1JNwhQx3KNlqz9q2sRV/Xxb71YSGEN nLqON4ipW32fcONgdTaA+TsnJw== X-Google-Smtp-Source: AA0mqf6GcDtWuq7A6v4bBbbht/rRQxdxBbsDvTtW7j1D9USVOdygPz0XjnNVRpkaQgPZt9texwKmfA== X-Received: by 2002:a17:902:c3d1:b0:188:82fc:e284 with SMTP id j17-20020a170902c3d100b0018882fce284mr1927093plj.76.1668163095189; Fri, 11 Nov 2022 02:38:15 -0800 (PST) Received: from google.com ([240f:75:7537:3187:8d55:c60d:579d:741c]) by smtp.gmail.com with ESMTPSA id l16-20020a170903121000b00176b84eb29asm117500plh.301.2022.11.11.02.38.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Nov 2022 02:38:14 -0800 (PST) Date: Fri, 11 Nov 2022 19:38:10 +0900 From: Sergey Senozhatsky To: Minchan Kim Cc: Sergey Senozhatsky , Andrew Morton , Nitin Gupta , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCHv4 2/9] zsmalloc: turn zspage order into runtime variable Message-ID: References: <20221031054108.541190-1-senozhatsky@chromium.org> <20221031054108.541190-3-senozhatsky@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668163096; a=rsa-sha256; cv=none; b=gIDrZvVpT+lecdQE3deKFxkpycyaWrFc3wsr2SkK6txNjvBycFtPMw9zUaVLyIs6ZV6lxs wfD4roTbY14rXCjImRYsrkoLBR4im4PNpLZsbJc/666srYt6nSpFu6xrTu0vSYGIeiFUti +QbS4tFS2oO4sWXIECV20BKOBkfZqCQ= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=FrAUhA4r; spf=pass (imf14.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.214.182 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=1668163096; 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=WDAe46mocv8N19iUrpVAVRFXORmPxnlQIO/wxgYUTno=; b=CTeymJf/5ASR2P46KuC83QguN2dbt8WC5n7yN0E/6KrBPztgwqW25eXoNfBiF5YGICnOn+ kqGct3+CyfZ1NEq+1hXfGrAWnBY60O59b0SI3RLo+joYWG2hIP7YeE3elFFM6jv4ZqaE/A GzCRpU2lbdb6GJBHhLkd1Ta+8GwQX/I= X-Stat-Signature: 8ak1xszfimizcfpe3nkjaunezeng599o X-Rspamd-Queue-Id: 3307510000E Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=FrAUhA4r; spf=pass (imf14.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.214.182 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1668163095-199325 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/11/10 13:59), Minchan Kim wrote: [..] > > +#define ZS_PAGE_ORDER_2 2 > > +#define ZS_PAGE_ORDER_4 4 > > + > > +/* > > + * A single 'zspage' is composed of up to 2^N discontiguous 0-order (single) > > + * pages. ZS_MAX_PAGE_ORDER defines upper limit on N, ZS_MIN_PAGE_ORDER > > + * defines lower limit on N. ZS_DEFAULT_PAGE_ORDER is recommended value. > > It gives the impression: > > 2^2 <= the page nubmer of zspage <= 2^4 > > I think that's not what you want to describe. How about? > > A single 'zspage' is composed of up to 2^N discontiguous 0-order (single) > pages and the N can be from ZS_MIN_PAGE_ORDER to ZS_MAX_PAGE_ORDER. OK. > > + */ > > +#define ZS_MIN_PAGE_ORDER ZS_PAGE_ORDER_2 > > +#define ZS_MAX_PAGE_ORDER ZS_PAGE_ORDER_4 > > +#define ZS_DEFAULT_PAGE_ORDER ZS_PAGE_ORDER_2 > > #define ZS_MIN_PAGE_ORDER 2 > > We can use the number directly instead of another wrapping at least > in this patch(Just in case: if you want to extent it later patch, > please do it in the patch) OK. [..] > > -#define MAX(a, b) ((a) >= (b) ? (a) : (b)) > > -/* ZS_MIN_ALLOC_SIZE must be multiple of ZS_ALIGN */ > > -#define ZS_MIN_ALLOC_SIZE \ > > - MAX(32, (ZS_MAX_PAGES_PER_ZSPAGE << PAGE_SHIFT >> OBJ_INDEX_BITS)) > > +#define ZS_MIN_ALLOC_SIZE 32U > > Let's have some comment here to say that's not the final vaule which > is supposed to be pool->min_alloc_size. OK. [..] > > enum fullness_group { > > ZS_EMPTY, > > @@ -230,12 +221,15 @@ struct link_free { > > struct zs_pool { > > const char *name; > > > > - struct size_class *size_class[ZS_SIZE_CLASSES]; > > + struct size_class **size_class; > > struct kmem_cache *handle_cachep; > > struct kmem_cache *zspage_cachep; > > > > atomic_long_t pages_allocated; > > > > + u32 num_size_classes; > > + u32 min_alloc_size; > > Please use int. OK. Any reason why we don't want u32? I thought that s16/u16/s32/u32/etc. is the new normal. > From this patch, I couldn't figure why we need > variable in the pool. Let's have the change in the patch where > you really need to have the usecase. Let me take a look. > > -static int get_pages_per_zspage(int class_size) > > +static int get_pages_per_zspage(u32 class_size, u32 num_pages) > > Let's just use int instead of u32 > > Why do you need num_pages argument instead of using 1UL << ZS_DEFAULT_PAGE_ORDER? > It looks like static value. It is static right now, but in the a couple of patches it'll change to dynamic.