From nobody Sun Sep 14 22:20:14 2025 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E5E5FC00A5A for ; Wed, 18 Jan 2023 01:02:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229484AbjARBCa (ORCPT ); Tue, 17 Jan 2023 20:02:30 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53948 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229537AbjARBB7 (ORCPT ); Tue, 17 Jan 2023 20:01:59 -0500 Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3111049946 for ; Tue, 17 Jan 2023 16:52:23 -0800 (PST) Received: by mail-pj1-x1033.google.com with SMTP id dw9so32756804pjb.5 for ; Tue, 17 Jan 2023 16:52:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=nkttQsu9CYNbqVs+SWUxgP6kf/grlmJh2/+ItE14A1E=; b=Eev0f7aYKnrE4GRG70azP9o2tu74O+ZYXgQ9BucWkBQ5FM/5i2gw0n6a0ytPEDUY34 NqCPhdY234pdbdl4KdLymrKkyHnTuyOC86MzD6DdZt33oz5vpXX+EX/zKeRe6sWnT8ce vxnYh7s6VkjLzd/SF89wzvvgAShJ9gBGQOGmw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=nkttQsu9CYNbqVs+SWUxgP6kf/grlmJh2/+ItE14A1E=; b=0kf8Bt90TPPmcZWdhhjwTm66nDvlnuciIax6rE/ZjIHJGiHL9PI7nKE+/gqUAA2dQz WI7odLwN/e8/12USRMrTh3pkNaG25BV6SccgjnFxgTbY5CWQxT6BlvMIDa4A3uduF9Z0 wE3tyc0wuPvoZvqXmVeED5zLsJU/p6Mt1dH9UqUCnKx1lRKDLcTF7GixuNu90ycuSHUk Tg7BF+nrNTi6yYD8itfbOBw2mwlQQ03+z68n1m1RxtZH2YFOtiFTRO+T0bMkHCNZj1Pg aqVN6xcUWQbsj+e3ijELdV/1oi/AdbQsa/OvuzRwT2ygv1nmfev40U9xQALjhRCqZFMN DN1g== X-Gm-Message-State: AFqh2kr8JdjW65b9WJws6TbtvTt5y6mDYl/ldqivB2QTaHMTIdoqJ5mu N9dEnSHhvWYW1qAjgWNYh/LGaQ== X-Google-Smtp-Source: AMrXdXsY7AyOsWXIqG+pfml6Gremcjag/qdnrV8bvDCBrr5vs4Og1jMyl/Drqe0slS2JWAsgBo6Y/A== X-Received: by 2002:a05:6a20:6f06:b0:ad:5cde:8f05 with SMTP id gt6-20020a056a206f0600b000ad5cde8f05mr4157965pzb.37.1674003142135; Tue, 17 Jan 2023 16:52:22 -0800 (PST) Received: from tigerii.tok.corp.google.com ([2401:fa00:8f:203:10f3:73a5:7e44:adbf]) by smtp.gmail.com with ESMTPSA id u10-20020a17090341ca00b00192f4fbdeb5sm8351461ple.102.2023.01.17.16.52.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Jan 2023 16:52:21 -0800 (PST) From: Sergey Senozhatsky To: Andrew Morton , Minchan Kim Cc: Mike Kravetz , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Sergey Senozhatsky Subject: [PATCHv3 1/4] zsmalloc: rework zspage chain size selection Date: Wed, 18 Jan 2023 09:52:07 +0900 Message-Id: <20230118005210.2814763-2-senozhatsky@chromium.org> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog In-Reply-To: <20230118005210.2814763-1-senozhatsky@chromium.org> References: <20230118005210.2814763-1-senozhatsky@chromium.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Computers are bad at division. We currently decide the best zspage chain size (max number of physical pages per-zspage) by looking at a `used percentage` value. This is not enough as we lose precision during usage percentage calculations For example, let's look at size class 208: pages per zspage wasted bytes used% 1 144 96 2 80 99 3 16 99 4 160 99 Current algorithm will select 2 page per zspage configuration, as it's the first one to reach 99%. However, 3 pages per zspage waste less memory. Change algorithm and select zspage configuration that has lowest wasted value. Signed-off-by: Sergey Senozhatsky Acked-by: Minchan Kim --- mm/zsmalloc.c | 56 +++++++++++++++++---------------------------------- 1 file changed, 19 insertions(+), 37 deletions(-) diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c index 6aafacd664fc..effe10fe76e9 100644 --- a/mm/zsmalloc.c +++ b/mm/zsmalloc.c @@ -802,42 +802,6 @@ static enum fullness_group fix_fullness_group(struct s= ize_class *class, return newfg; } =20 -/* - * We have to decide on how many pages to link together - * to form a zspage for each size class. This is important - * to reduce wastage due to unusable space left at end of - * each zspage which is given as: - * wastage =3D Zp % class_size - * usage =3D Zp - wastage - * where Zp =3D zspage size =3D k * PAGE_SIZE where k =3D 1, 2, ... - * - * For example, for size class of 3/8 * PAGE_SIZE, we should - * link together 3 PAGE_SIZE sized pages to form a zspage - * since then we can perfectly fit in 8 such objects. - */ -static int get_pages_per_zspage(int class_size) -{ - int i, max_usedpc =3D 0; - /* zspage order which gives maximum used size per KB */ - int max_usedpc_order =3D 1; - - for (i =3D 1; i <=3D ZS_MAX_PAGES_PER_ZSPAGE; i++) { - int zspage_size; - int waste, usedpc; - - zspage_size =3D i * PAGE_SIZE; - waste =3D zspage_size % class_size; - usedpc =3D (zspage_size - waste) * 100 / zspage_size; - - if (usedpc > max_usedpc) { - max_usedpc =3D usedpc; - max_usedpc_order =3D i; - } - } - - return max_usedpc_order; -} - static struct zspage *get_zspage(struct page *page) { struct zspage *zspage =3D (struct zspage *)page_private(page); @@ -2318,6 +2282,24 @@ static int zs_register_shrinker(struct zs_pool *pool) pool->name); } =20 +static int calculate_zspage_chain_size(int class_size) +{ + int i, min_waste =3D INT_MAX; + int chain_size =3D 1; + + for (i =3D 1; i <=3D ZS_MAX_PAGES_PER_ZSPAGE; i++) { + int waste; + + waste =3D (i * PAGE_SIZE) % class_size; + if (waste < min_waste) { + min_waste =3D waste; + chain_size =3D i; + } + } + + return chain_size; +} + /** * zs_create_pool - Creates an allocation pool to work from. * @name: pool name to be created @@ -2362,7 +2344,7 @@ struct zs_pool *zs_create_pool(const char *name) size =3D ZS_MIN_ALLOC_SIZE + i * ZS_SIZE_CLASS_DELTA; if (size > ZS_MAX_ALLOC_SIZE) size =3D ZS_MAX_ALLOC_SIZE; - pages_per_zspage =3D get_pages_per_zspage(size); + pages_per_zspage =3D calculate_zspage_chain_size(size); objs_per_zspage =3D pages_per_zspage * PAGE_SIZE / size; =20 /* --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun Sep 14 22:20:14 2025 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6C6DCC00A5A for ; Wed, 18 Jan 2023 01:03:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229889AbjARBDF (ORCPT ); Tue, 17 Jan 2023 20:03:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53920 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229635AbjARBCL (ORCPT ); Tue, 17 Jan 2023 20:02:11 -0500 Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F0DFB53E63 for ; Tue, 17 Jan 2023 16:52:28 -0800 (PST) Received: by mail-pl1-x62a.google.com with SMTP id jl3so233535plb.8 for ; Tue, 17 Jan 2023 16:52:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=wlEuvLJ1OIwhsVr6jP4j+nVp1P/tzWBP4lAYnG/eYgY=; b=TLu9c0Cj9B2z19rRraJKbiywIrmYs/BVdE12dMxlvW8Y149yooSO39yxohc5u8cq2d iUC1z81ahFo78NQK8aD1I9A9YnnL2f69pBet4g2EhZAiqQHWUM3UP/Cm/nQMw5XYJU1D himUcbF+wJEhI9kS2XeqnPuGlUxxUFPHNZCXQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=wlEuvLJ1OIwhsVr6jP4j+nVp1P/tzWBP4lAYnG/eYgY=; b=cHVPa+DUHoTThxVUqPSes177OJAelT2UzQ5+qOqEpDpAVmTpTnonIfmqtFG27E+z5s IYXgkAALEYHMUa5t1xgQNegCgoDlijdgrXk9ssp4TCR3ZLnT2Poylazg4WqHqWeUrjEe uGBZ1dIXiS5XEhnn5TGLi9TzTgyaISPRWmf0bBSvHSvsLtoepXldYspNyltL2lfcSIhQ 7aQTFYGxZSEiiFxPfQyN5AShpECIik5E4j6BY0jB7MC6n2WeiOOPuynh8fZSfIHygLEJ cxe8D9c5xV/8JA9BCgIB9VQ4MWcWe6Z07XyQ+sdHnC0jUkziA7y2qnaWsxqDZCdBcUSF yDEw== X-Gm-Message-State: AFqh2koiKouAwK9zod40noTQ22SiOJkXDPVAINOP7t5ciAslptT4Syvl EOhcA8rJGeIpnz19l2dXUAHrXw== X-Google-Smtp-Source: AMrXdXvg3Wmcxlr+zxIzbctf0szk1Alr8VFtzl74qmArJYWCAlwZt9atsHWVsv5Y4QATS8R33CZw/w== X-Received: by 2002:a17:902:8d94:b0:192:d9dd:167d with SMTP id v20-20020a1709028d9400b00192d9dd167dmr4633379plo.43.1674003146107; Tue, 17 Jan 2023 16:52:26 -0800 (PST) Received: from tigerii.tok.corp.google.com ([2401:fa00:8f:203:10f3:73a5:7e44:adbf]) by smtp.gmail.com with ESMTPSA id u10-20020a17090341ca00b00192f4fbdeb5sm8351461ple.102.2023.01.17.16.52.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Jan 2023 16:52:25 -0800 (PST) From: Sergey Senozhatsky To: Andrew Morton , Minchan Kim Cc: Mike Kravetz , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Sergey Senozhatsky Subject: [PATCHv3 2/4] zsmalloc: skip chain size calculation for pow_of_2 classes Date: Wed, 18 Jan 2023 09:52:08 +0900 Message-Id: <20230118005210.2814763-3-senozhatsky@chromium.org> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog In-Reply-To: <20230118005210.2814763-1-senozhatsky@chromium.org> References: <20230118005210.2814763-1-senozhatsky@chromium.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" If a class size is power of 2 then it wastes no memory and the best configuration is 1 physical page per-zspage. Signed-off-by: Sergey Senozhatsky Acked-by: Minchan Kim --- mm/zsmalloc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c index effe10fe76e9..ee8431784998 100644 --- a/mm/zsmalloc.c +++ b/mm/zsmalloc.c @@ -2287,6 +2287,9 @@ static int calculate_zspage_chain_size(int class_size) int i, min_waste =3D INT_MAX; int chain_size =3D 1; =20 + if (is_power_of_2(class_size)) + return chain_size; + for (i =3D 1; i <=3D ZS_MAX_PAGES_PER_ZSPAGE; i++) { int waste; =20 --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun Sep 14 22:20:14 2025 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7A802C00A5A for ; Wed, 18 Jan 2023 01:03:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229744AbjARBDP (ORCPT ); Tue, 17 Jan 2023 20:03:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54030 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229946AbjARBCO (ORCPT ); Tue, 17 Jan 2023 20:02:14 -0500 Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4C30149944 for ; Tue, 17 Jan 2023 16:52:30 -0800 (PST) Received: by mail-pl1-x631.google.com with SMTP id k13so2720892plg.0 for ; Tue, 17 Jan 2023 16:52:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=CIIcftnTzg8Kfx+49Y7UDaJ1lnEPtZ3NItF9OqS/fDU=; b=dKn2e93spigc03KLoXF7ZTvVdGY4XHGNHnI/QVdRnTJdStKDXdwLMk4o7DqqMfWHHO T/G/I+6eLpYdy/tTV7clT0V0xsm+nkJuExMO/sXyx4IPTW38Qde+EdFSLKH1HHZQzPnc VV5m4HySicj9ZEu9Ag3VnYKm5AY5GJ635n4JU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=CIIcftnTzg8Kfx+49Y7UDaJ1lnEPtZ3NItF9OqS/fDU=; b=IYVD7iM3hgeqhMGfzjYX5Admnhn8+YP2XTsSbBYv65vtcGA5Hh4H7nyYY6awD9cRL8 t6JxfRAKqVXZK5OEw3VaATxINmg/plqwpZ3f7x32Jv97d90yvp2YikjAXwY7qPcmTMQ4 BSWse7va9MlURN5HTHyJHc89z4m8d1i8n9MoMYTeVxpldDqE1qbAeG5Se3LxrpTLcX1+ kYeDOPJTU5yCTbI1HsRnKhgTGzgtH+pukDg+9HOH9uV13gpF/adz92Uos9baZolppgVj QpzvkWsprvbCT8myy7RKnOQtYwaUE7vo4WEPJzq4lsjdSh2Fr6g1bAioo+90z5LfAPpH 1Vcw== X-Gm-Message-State: AFqh2kqyzugB0wXG3EXbFt85FkkuFOY70jP3TjHMtH0G/4UssR11tbNr +riux/7qwlcoENrRtU3/bo7FTQ== X-Google-Smtp-Source: AMrXdXt+yEbHb017zotxisctz8oAkeMlBJeMXC+abT7hLpAAamlMLlet/dkMa+wmQJxZGPxJa539Uw== X-Received: by 2002:a17:902:aa05:b0:194:52ed:7a2b with SMTP id be5-20020a170902aa0500b0019452ed7a2bmr5362165plb.39.1674003149509; Tue, 17 Jan 2023 16:52:29 -0800 (PST) Received: from tigerii.tok.corp.google.com ([2401:fa00:8f:203:10f3:73a5:7e44:adbf]) by smtp.gmail.com with ESMTPSA id u10-20020a17090341ca00b00192f4fbdeb5sm8351461ple.102.2023.01.17.16.52.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Jan 2023 16:52:28 -0800 (PST) From: Sergey Senozhatsky To: Andrew Morton , Minchan Kim Cc: Mike Kravetz , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Sergey Senozhatsky Subject: [PATCHv3 3/4] zsmalloc: make zspage chain size configurable Date: Wed, 18 Jan 2023 09:52:09 +0900 Message-Id: <20230118005210.2814763-4-senozhatsky@chromium.org> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog In-Reply-To: <20230118005210.2814763-1-senozhatsky@chromium.org> References: <20230118005210.2814763-1-senozhatsky@chromium.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Remove hard coded limit on the maximum number of physical pages per-zspage. This will allow tuning of zsmalloc pool as zspage chain size changes `pages per-zspage` and `objects per-zspage` characteristics of size classes which also affects size classes clustering (the way size classes are merged). Signed-off-by: Sergey Senozhatsky Acked-by: Minchan Kim --- Documentation/mm/zsmalloc.rst | 168 ++++++++++++++++++++++++++++++++++ mm/Kconfig | 19 ++++ mm/zsmalloc.c | 12 +-- 3 files changed, 191 insertions(+), 8 deletions(-) diff --git a/Documentation/mm/zsmalloc.rst b/Documentation/mm/zsmalloc.rst index 6e79893d6132..40323c9b39d8 100644 --- a/Documentation/mm/zsmalloc.rst +++ b/Documentation/mm/zsmalloc.rst @@ -80,3 +80,171 @@ Similarly, we assign zspage to: * ZS_ALMOST_FULL when n > N / f * ZS_EMPTY when n =3D=3D 0 * ZS_FULL when n =3D=3D N + + +Internals +=3D=3D=3D=3D=3D=3D=3D=3D=3D + +zsmalloc has 255 size classes, each of which can hold a number of zspages. +Each zspage can contain up to ZSMALLOC_CHAIN_SIZE physical (0-order) pages. +The optimal zspage chain size for each size class is calculated during the +creation of the zsmalloc pool (see calculate_zspage_chain_size()). + +As an optimization, zsmalloc merges size classes that have similar +characteristics in terms of the number of pages per zspage and the number +of objects that each zspage can store. + +For instance, consider the following size classes::: + + class size almost_full almost_empty obj_allocated obj_used pages_used= pages_per_zspage freeable + ... + 94 1536 0 0 0 0 0= 3 0 + 100 1632 0 0 0 0 0= 2 0 + ... + + +Size classes #95-99 are merged with size class #100. This means that when = we +need to store an object of size, say, 1568 bytes, we end up using size cla= ss +#100 instead of size class #96. Size class #100 is meant for objects of si= ze +1632 bytes, so each object of size 1568 bytes wastes 1632-1568=3D64 bytes. + +Size class #100 consists of zspages with 2 physical pages each, which can +hold a total of 5 objects. If we need to store 13 objects of size 1568, we +end up allocating three zspages, or 6 physical pages. + +However, if we take a closer look at size class #96 (which is meant for +objects of size 1568 bytes) and trace `calculate_zspage_chain_size()`, we +find that the most optimal zspage configuration for this class is a chain +of 5 physical pages::: + + pages per zspage wasted bytes used% + 1 960 76 + 2 352 95 + 3 1312 89 + 4 704 95 + 5 96 99 + +This means that a class #96 configuration with 5 physical pages can store = 13 +objects of size 1568 in a single zspage, using a total of 5 physical pages. +This is more efficient than the class #100 configuration, which would use 6 +physical pages to store the same number of objects. + +As the zspage chain size for class #96 increases, its key characteristics +such as pages per-zspage and objects per-zspage also change. This leads to +dewer class mergers, resulting in a more compact grouping of classes, which +reduces memory wastage. + +Let's take a closer look at the bottom of `/sys/kernel/debug/zsmalloc/zram= X/classes`::: + + class size almost_full almost_empty obj_allocated obj_used pages_used= pages_per_zspage freeable + ... + 202 3264 0 0 0 0 0= 4 0 + 254 4096 0 0 0 0 0= 1 0 + ... + +Size class #202 stores objects of size 3264 bytes and has a maximum of 4 p= ages +per zspage. Any object larger than 3264 bytes is considered huge and belon= gs +to size class #254, which stores each object in its own physical page (obj= ects +in huge classes do not share pages). + +Increasing the size of the chain of zspages also results in a higher water= mark +for the huge size class and fewer huge classes overall. This allows for mo= re +efficient storage of large objects. + +For zspage chain size of 8, huge class watermark becomes 3632 bytes::: + + class size almost_full almost_empty obj_allocated obj_used pages_used= pages_per_zspage freeable + ... + 202 3264 0 0 0 0 0= 4 0 + 211 3408 0 0 0 0 0= 5 0 + 217 3504 0 0 0 0 0= 6 0 + 222 3584 0 0 0 0 0= 7 0 + 225 3632 0 0 0 0 0= 8 0 + 254 4096 0 0 0 0 0= 1 0 + ... + +For zspage chain size of 16, huge class watermark becomes 3840 bytes::: + + class size almost_full almost_empty obj_allocated obj_used pages_used= pages_per_zspage freeable + ... + 202 3264 0 0 0 0 0= 4 0 + 206 3328 0 0 0 0 0= 13 0 + 207 3344 0 0 0 0 0= 9 0 + 208 3360 0 0 0 0 0= 14 0 + 211 3408 0 0 0 0 0= 5 0 + 212 3424 0 0 0 0 0= 16 0 + 214 3456 0 0 0 0 0= 11 0 + 217 3504 0 0 0 0 0= 6 0 + 219 3536 0 0 0 0 0= 13 0 + 222 3584 0 0 0 0 0= 7 0 + 223 3600 0 0 0 0 0= 15 0 + 225 3632 0 0 0 0 0= 8 0 + 228 3680 0 0 0 0 0= 9 0 + 230 3712 0 0 0 0 0= 10 0 + 232 3744 0 0 0 0 0= 11 0 + 234 3776 0 0 0 0 0= 12 0 + 235 3792 0 0 0 0 0= 13 0 + 236 3808 0 0 0 0 0= 14 0 + 238 3840 0 0 0 0 0= 15 0 + 254 4096 0 0 0 0 0= 1 0 + ... + +Overall the combined zspage chain size effect on zsmalloc pool configurati= on::: + + pages per zspage number of size classes (clusters) huge size class w= atermark + 4 69 3264 + 5 86 3408 + 6 93 3504 + 7 112 3584 + 8 123 3632 + 9 140 3680 + 10 143 3712 + 11 159 3744 + 12 164 3776 + 13 180 3792 + 14 183 3808 + 15 188 3840 + 16 191 3840 + + +A synthetic test +---------------- + +zram as a build artifacts storage (Linux kernel compilation). + +* `CONFIG_ZSMALLOC_CHAIN_SIZE=3D4` + + zsmalloc classes stats::: + + class size almost_full almost_empty obj_allocated obj_used pages_us= ed pages_per_zspage freeable + ... + Total 13 51 413836 412973 1599= 55 3 + + zram mm_stat::: + + 1691783168 628083717 655175680 0 655175680 60 0 = 34048 34049 + + +* `CONFIG_ZSMALLOC_CHAIN_SIZE=3D8` + + zsmalloc classes stats::: + + class size almost_full almost_empty obj_allocated obj_used pages_us= ed pages_per_zspage freeable + ... + Total 18 87 414852 412978 1566= 66 0 + + zram mm_stat::: + + 1691803648 627793930 641703936 0 641703936 60 0 = 33591 33591 + +Using larger zspage chains may result in using fewer physical pages, as se= en +in the example where the number of physical pages used decreased from 1599= 55 +to 156666, at the same time maximum zsmalloc pool memory usage went down f= rom +655175680 to 641703936 bytes. + +However, this advantage may be offset by the potential for increased system +memory pressure (as some zspages have larger chain sizes) in cases where t= here +is heavy internal fragmentation and zspool compaction is unable to relocate +objects and release zspages. In these cases, it is recommended to decrease +the limit on the size of the zspage chains (as specified by the +CONFIG_ZSMALLOC_CHAIN_SIZE option). diff --git a/mm/Kconfig b/mm/Kconfig index 4eb4afa53e6d..1cfc0ec4e35e 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -191,6 +191,25 @@ config ZSMALLOC_STAT information to userspace via debugfs. If unsure, say N. =20 +config ZSMALLOC_CHAIN_SIZE + int "Maximum number of physical pages per-zspage" + default 4 + range 4 16 + depends on ZSMALLOC + help + This option sets the upper limit on the number of physical pages + that a zmalloc page (zspage) can consist of. The optimal zspage + chain size is calculated for each size class during the + initialization of the pool. + + Changing this option can alter the characteristics of size classes, + such as the number of pages per zspage and the number of objects + per zspage. This can also result in different configurations of + the pool, as zsmalloc merges size classes with similar + characteristics. + + For more information, see zsmalloc documentation. + menu "SLAB allocator options" =20 choice diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c index ee8431784998..1a7f68c46ccd 100644 --- a/mm/zsmalloc.c +++ b/mm/zsmalloc.c @@ -73,13 +73,6 @@ */ #define ZS_ALIGN 8 =20 -/* - * A single 'zspage' is composed of up to 2^N discontiguous 0-order (singl= e) - * pages. ZS_MAX_ZSPAGE_ORDER defines upper limit on N. - */ -#define ZS_MAX_ZSPAGE_ORDER 2 -#define ZS_MAX_PAGES_PER_ZSPAGE (_AC(1, UL) << ZS_MAX_ZSPAGE_ORDER) - #define ZS_HANDLE_SIZE (sizeof(unsigned long)) =20 /* @@ -120,10 +113,13 @@ #define HUGE_BITS 1 #define FULLNESS_BITS 2 #define CLASS_BITS 8 -#define ISOLATED_BITS 3 +#define ISOLATED_BITS 5 #define MAGIC_VAL_BITS 8 =20 #define MAX(a, b) ((a) >=3D (b) ? (a) : (b)) + +#define ZS_MAX_PAGES_PER_ZSPAGE (_AC(CONFIG_ZSMALLOC_CHAIN_SIZE, UL)) + /* 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)) --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun Sep 14 22:20:14 2025 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9942EC00A5A for ; Wed, 18 Jan 2023 01:03:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229662AbjARBDU (ORCPT ); Tue, 17 Jan 2023 20:03:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54064 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229944AbjARBCO (ORCPT ); Tue, 17 Jan 2023 20:02:14 -0500 Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 106994900E for ; Tue, 17 Jan 2023 16:52:33 -0800 (PST) Received: by mail-pj1-x1031.google.com with SMTP id s13-20020a17090a6e4d00b0022900843652so695243pjm.1 for ; Tue, 17 Jan 2023 16:52:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=EsTMdrrDLcqpHJRbM6PDDky4/t4qR5IEdsq7S2Y6nHw=; b=Fz8NyEIRMQqp+I4ZCxQepR1p8/ydkvg2hf1HWGJ8u/aCQ9zbwbo77E3dYl7YNtJc4i BUn0gxOOa7Ai0hZJHABejQtg+WfubPi/k0+hJgmX2tztw22xre3y8cf3ZlgKFEFs+OLF +bW3L/RBjQHekHwrqA7plGbudq0By7lrRWw8o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=EsTMdrrDLcqpHJRbM6PDDky4/t4qR5IEdsq7S2Y6nHw=; b=KAalYOr28s1hD19EoV5IbAPI+tiqAtKi/E/+NRjINvYDFJZ8y3bxu0Ixf6Cu9Pv47X 6KR6f1vZ7a9SXTu1XUjLYuK60BqIaYYd63odGh3IKcvPYycd3gaZG+6K0Ebg2NeMY2Or mUCPmu5phmux/6zu2juEKWttDkfNg8YLi9DEVB4HBS0uZmVSfAbW9Q0sNIYQODoE/qLW p/4VnecEMCKiPDoGudxZOFYnRlp5rEdMN6dABqBTg1V8qDm7OlZElqktCd0+HCPMgs+r vgmVK+FUXLH+PKXpHaq2I1MM+kG9SzmuZS04sjdbUPh3zYq5n81UEBz49KkdNK8dvJFj DAxQ== X-Gm-Message-State: AFqh2kr7koyD6PiS+n+FF3RBZtHDVseZk+s6MjxaxM/yw4TRKeZ0sHLK 8JVtRNtRulyVm2NVi5VlD20gwg== X-Google-Smtp-Source: AMrXdXsdNKdUiGRGfP8RIbqx3A82w0/9Ni8LqjvhCZZQjbuQ2HELZUicdwQGq1iTQV8GzoNc5bTcWQ== X-Received: by 2002:a17:902:8208:b0:193:f76:aed4 with SMTP id x8-20020a170902820800b001930f76aed4mr5345353pln.1.1674003152775; Tue, 17 Jan 2023 16:52:32 -0800 (PST) Received: from tigerii.tok.corp.google.com ([2401:fa00:8f:203:10f3:73a5:7e44:adbf]) by smtp.gmail.com with ESMTPSA id u10-20020a17090341ca00b00192f4fbdeb5sm8351461ple.102.2023.01.17.16.52.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Jan 2023 16:52:31 -0800 (PST) From: Sergey Senozhatsky To: Andrew Morton , Minchan Kim Cc: Mike Kravetz , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Sergey Senozhatsky Subject: [PATCHv3 4/4] zsmalloc: set default zspage chain size to 8 Date: Wed, 18 Jan 2023 09:52:10 +0900 Message-Id: <20230118005210.2814763-5-senozhatsky@chromium.org> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog In-Reply-To: <20230118005210.2814763-1-senozhatsky@chromium.org> References: <20230118005210.2814763-1-senozhatsky@chromium.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" This changes key characteristics (pages per-zspage and objects per-zspage) of a number of size classes which in results in different pool configuration. With zspage chain size of 8 we have more size clases clusters (123) and higher huge size class watermark (3632 bytes). Please read zsmalloc documentation for more details. Signed-off-by: Sergey Senozhatsky Acked-by: Minchan Kim --- mm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/Kconfig b/mm/Kconfig index 1cfc0ec4e35e..ebfe5796adf8 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -193,7 +193,7 @@ config ZSMALLOC_STAT =20 config ZSMALLOC_CHAIN_SIZE int "Maximum number of physical pages per-zspage" - default 4 + default 8 range 4 16 depends on ZSMALLOC help --=20 2.39.0.314.g84b9a713c41-goog