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 C9169C3DA6D for ; Tue, 20 May 2025 23:15:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4C7D56B0083; Tue, 20 May 2025 19:15:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 478646B0085; Tue, 20 May 2025 19:15:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 366D16B0088; Tue, 20 May 2025 19:15:02 -0400 (EDT) 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 17AF96B0083 for ; Tue, 20 May 2025 19:15:02 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 26B411616D5 for ; Tue, 20 May 2025 23:15:01 +0000 (UTC) X-FDA: 83464843602.14.2653B0E Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) by imf08.hostedemail.com (Postfix) with ESMTP id 267CA16000C for ; Tue, 20 May 2025 23:14:58 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=0XNbXLT7; spf=pass (imf08.hostedemail.com: domain of jyescas@google.com designates 209.85.160.179 as permitted sender) smtp.mailfrom=jyescas@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1747782899; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=VwKDYk+LUh/66D5vXsuMYGfvDobJ3NQ267JBjwa/l8M=; b=DTYnGS8GSbY5yjsBfvixZwhOyDOIbvwhMA4elrAZ/FXTO9ap2ELOU9pZFrmgOuLtQptkC1 tBFKQ/2wGVw6dvA1254kd6l05S+4PmyXfOU+tvb3Iwvt3puqt3uqpll00rVlPGolxgB3Dz 4P3QrM9MfQBMok5h0SCMLVCXCLKVBgA= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=0XNbXLT7; spf=pass (imf08.hostedemail.com: domain of jyescas@google.com designates 209.85.160.179 as permitted sender) smtp.mailfrom=jyescas@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747782899; a=rsa-sha256; cv=none; b=HD/UKh4t2i/A+gI0Uk00WDKb9YKiv/SdYmU/FjrtyWJAAHyC5/sH+/enHDmwoDUpr+7diP Q5ArXeoXcAqAS8ObDJzQMHFFzWiBwpYMkgg8t0fOUEhIAQhXa8xLBTdbum3lQrikUcUG9g rg5tYpgsdRyqOibUK8CeuN62py7BOUk= Received: by mail-qt1-f179.google.com with SMTP id d75a77b69052e-48b7747f881so1243791cf.1 for ; Tue, 20 May 2025 16:14:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1747782898; x=1748387698; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=VwKDYk+LUh/66D5vXsuMYGfvDobJ3NQ267JBjwa/l8M=; b=0XNbXLT7Ge+tRa4CG5c2pP4a0c1HVYmQCzFfd6KDD9UeZSlklqobMrD2w3+ubB2le/ +BaRFfr1l2w/3IbRfVW6rCbsxUl2UA9UHkB2vAduIF6iBxf2TpBomsfJrdl5qHyWQXai +Out1+qRwKMFT/QQ3IYSDdKFYC3gdPtmMXIgrbSjg4VC3eHVs8Vh68qNhcmrH3mlRURM MBe71wzS8U/5aJb0hCHMOcWZo2tFHIERreOCkYtGNIdwJut3vgqFZtMwjUcllENNtarb F7FLcsEYvENvyWia+pCD3YDvh09IjKy5yxZCvbjK0gSdRF9aG+vhDV3PCVkBYNpubCeh iaCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747782898; x=1748387698; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=VwKDYk+LUh/66D5vXsuMYGfvDobJ3NQ267JBjwa/l8M=; b=wQiPcO557nAz+KfS5lwBJ/aCmaVuBcn1kfBxqNk310L5ND1osv9F8Q8uJ9v1FZZprx 7m+yGhs9FkFABelWLwFuZ41r0K/ed8yQguk0cWrR/SweKwlnsCgam5kBc1cLa7Vhq0Y9 gxp+PSvgNf2cI22saupd+K/4n6wcAFTcLlsQgdsQXIl4rQBAcu9bJc3hAtnYs5/ZwB9z wIOH0gt25xRIKJ0VCQAtNrLaxyp8Gw8A4bAW3qu/vRqGYAGoPIaepTbu9smBQDLUrZ26 FBQZjXUWccgd7yOTI0UGhdmf7ek6DGH3amk7Vpv/JvQjoYRb6MxTQZi3mq3YTASmA7M0 ioKg== X-Forwarded-Encrypted: i=1; AJvYcCXneOCCCGFBgT8mzL8PO3r/g/xRZnqKQScMFr9K0fQl48MkeQgbScSSUPaoO/f559xiFKT1rKcCGA==@kvack.org X-Gm-Message-State: AOJu0Yzd6+UYxsoyDSsB/iPs0+2KyHYUQnv1vqiURcpgqC6L1u6M+a8c g44rHiW72Ck+ALrW7n89FYlGWg/ArIiaFxto2k7sbQV9YvOVWyeGOmN9Mefow+S5PCi8Pf9mpBE ZU92Dff3jUmnNgwHw+rDh9KpApb0sVGDJU8jgTtEa X-Gm-Gg: ASbGncsnDRrs+J5ojuyAOInonJdBL4oizBzuK6t7dJncCQRqZusfMsw9uYF+VnxvwDC vrwPgwaa+7XvpzcKbbzlch/hvWg7zz15K1qfWlrYhRhUUoTFf5CTFLUQ2vVpuUiFdAmTGaQasNw k+9OahBqRqOTeOl4awjAymIeHB/zq8jMQI2e4nbsE/GrR/UeKISFjqFCP5/jMOOLHpJc/mqwKM X-Google-Smtp-Source: AGHT+IGaU9BQ83k0ZRoBuYykShd6kgLdiRzG5qNoS7Gd2LDAPwLl0KN6KvyLD/qSbh0UhKFqfBYB3h34mTYWTrXD3s8= X-Received: by 2002:ac8:5a8e:0:b0:477:8686:901d with SMTP id d75a77b69052e-495ff6d3f0dmr12920411cf.1.1747782897668; Tue, 20 May 2025 16:14:57 -0700 (PDT) MIME-Version: 1.0 References: <20250510010338.3978696-1-jyescas@google.com> <8E999CBA-6F55-4DCA-8BE3-569B1C537802@nvidia.com> In-Reply-To: <8E999CBA-6F55-4DCA-8BE3-569B1C537802@nvidia.com> From: Juan Yescas Date: Tue, 20 May 2025 16:14:46 -0700 X-Gm-Features: AX0GCFtC-z_Cx3cMi0nT69lR5itEQxl7k2LfSNYQdr27xoRVSQ0DmIhnpcZUc7M Message-ID: Subject: Re: [PATCH v4] mm: Add CONFIG_PAGE_BLOCK_ORDER to select page block order To: Zi Yan Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, tjmercier@google.com, isaacmanjarres@google.com, surenb@google.com, kaleshsingh@google.com, Vlastimil Babka , "Liam R. Howlett" , Lorenzo Stoakes , David Hildenbrand , Mike Rapoport , Minchan Kim Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam10 X-Stat-Signature: zxonkmze1wmjxdscnay1nquhc11znjgs X-Rspamd-Queue-Id: 267CA16000C X-Rspam-User: X-HE-Tag: 1747782898-800043 X-HE-Meta: U2FsdGVkX19QfYl2QNJHr1Pc07JVZSsruaZkCeMIbU+euOTNjzsI4vAt7Qhk/B8HjNSmfBXNWSFMW4yk+g1ceoFUFhNsfCsUXSO91+ISZaF5nSMw37OYJ2X1EyXwKzq1M9Z8DZmGp11uh2Q5N4D4C0hsJQaPlGNx9oVLR3KeeBB1pl/4pj5mnIwAiY/0XP0C3Fz1epuIJELeOcaigZ8BBPkAVTnPOY56uhW+V1JtjhC31lkM9aeorMQeZvBNINghFXTGb4lGeBkMfvkGOR52bNft5gKsMLSnCVJ7K2wC4fwOY93RLaBe/7+49gn1pze8DpVGQ3DXtg3hjvxY/T3aJGxJKhSpiEWujTbMyTTIvHQMPHVvi8t0xjS2rcv74AemeRfUxoRDLVPuerkj2hf/u02F8qyeYLPWDJ7x8fOZa1gl/pauaLXZJl/vFSTgaCjP5+SmmfnYuzataNCG+ZF/iaMc4AUIsxrf5QYrCZJynDvDvgKe08eC3etq8C51VSocoR2ljrmUOp4ysIP/ThHGaxas8tuapZFhxvDud2T+970WYLvXGMjwsoeNtQtSUqjDPn2hiEvrVPZPHdXIPdXBy49uYPrdVQyd9J9fNQwQld+TTbCi1hv1lZPsc7hKEnQI3+0dtqE18+ATgDWu1KgDutHJpV/bbDPG4ZLu2Cvm7SoEklgYaKnGHKYQxOWyiAUUiX2bx/NgYycoO12LedplMSCuXSE+fJDyqhdGgvceXDOL98DLrKRKhCHqMBTVoi6AKYwhjp/7jRpNHmfgos8UJHZ2qeElmYyJVq69yTKh801IFBSTAnn4zN7B21jFQI3AB11TwmJz+HIk2cIm0gsFWP0b4piRcb1Qe6e0tD/W2nMEuWho2CYNiMZYTGKVYbUjDu+o9RNL3SHOvaEQz1/RQWJ9PSXiwrrN/bfwB8BoeWnowJZ9DFCERsMhZC7ehkPe/2QAXurHRE9nxz2+oVj urhQtBcp Di8CLoST0pTbuZyyRBA6TCk/z+InqPjW/wEjHv2uCgOm43AWK4zcltm1pBoriUaqJK5j9Y0tAbwYeVt57HMTSP81I+OR7RXGTeD+V2uo+/lCIOrQBsGuZt4o6RbbNGnZOr49iUFI/Zg9VVWpWaS1inaKGV/dG9Nzr12X6mnfKW/Jms+M9211uRiopcbg3MHnfyjJ7nYzILTE8ohmR72WdKQP0zXhKayEzZSgDaE2e77Fa3Lef/lA7eR4eBTBww1YogeVSa2sM0uUHpiEIZ76JE4Yq6gyKYoZUnlPpi/JXb4p7+GERRBXjdXzwZ8kA6uenfjqwni9VciBdtIzOGnPSU0BVAE/5cxS4131R2ZTW2SmUiPIR7ogUsGNK0m6iwKxwyWzk1XH2Dal7pGITyOIU+WskYdc1BWQBTiaaOLYJ3X8lYyfn2rJ6q7wvI9T9aR/81sD3hj9j8wNXahhjxqbZmUiF0e+RM+sK6hJbCvlssIfVMnIp02NJtMH4orOkTen2X5aJX5Tr02WznRU= 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: List-Subscribe: List-Unsubscribe: On Sat, May 17, 2025 at 11:51=E2=80=AFAM Zi Yan wrote: > > On 9 May 2025, at 21:02, Juan Yescas wrote: > > > Problem: On large page size configurations (16KiB, 64KiB), the CMA > > alignment requirement (CMA_MIN_ALIGNMENT_BYTES) increases considerably, > > and this causes the CMA reservations to be larger than necessary. > > This means that system will have less available MIGRATE_UNMOVABLE and > > MIGRATE_RECLAIMABLE page blocks since MIGRATE_CMA can't fallback to the= m. > > > > The CMA_MIN_ALIGNMENT_BYTES increases because it depends on > > MAX_PAGE_ORDER which depends on ARCH_FORCE_MAX_ORDER. The value of > > ARCH_FORCE_MAX_ORDER increases on 16k and 64k kernels. > > > > For example, in ARM, the CMA alignment requirement when: > > > > - CONFIG_ARCH_FORCE_MAX_ORDER default value is used > > - CONFIG_TRANSPARENT_HUGEPAGE is set: > > > > PAGE_SIZE | MAX_PAGE_ORDER | pageblock_order | CMA_MIN_ALIGNMENT_BYTES > > ----------------------------------------------------------------------- > > 4KiB | 10 | 10 | 4KiB * (2 ^ 10) =3D 4= MiB > > 16Kib | 11 | 11 | 16KiB * (2 ^ 11) =3D 32= MiB > > 64KiB | 13 | 13 | 64KiB * (2 ^ 13) =3D 512= MiB > > > > There are some extreme cases for the CMA alignment requirement when: > > > > - CONFIG_ARCH_FORCE_MAX_ORDER maximum value is set > > - CONFIG_TRANSPARENT_HUGEPAGE is NOT set: > > - CONFIG_HUGETLB_PAGE is NOT set > > > > PAGE_SIZE | MAX_PAGE_ORDER | pageblock_order | CMA_MIN_ALIGNMENT_BYTES > > -----------------------------------------------------------------------= - > > 4KiB | 15 | 15 | 4KiB * (2 ^ 15) =3D 128= MiB > > 16Kib | 13 | 13 | 16KiB * (2 ^ 13) =3D 128= MiB > > 64KiB | 13 | 13 | 64KiB * (2 ^ 13) =3D 512= MiB > > > > This affects the CMA reservations for the drivers. If a driver in a > > 4KiB kernel needs 4MiB of CMA memory, in a 16KiB kernel, the minimal > > reservation has to be 32MiB due to the alignment requirements: > > > > reserved-memory { > > ... > > cma_test_reserve: cma_test_reserve { > > compatible =3D "shared-dma-pool"; > > size =3D <0x0 0x400000>; /* 4 MiB */ > > ... > > }; > > }; > > > > reserved-memory { > > ... > > cma_test_reserve: cma_test_reserve { > > compatible =3D "shared-dma-pool"; > > size =3D <0x0 0x2000000>; /* 32 MiB */ > > ... > > }; > > }; > > > > Solution: Add a new config CONFIG_PAGE_BLOCK_ORDER that > > allows to set the page block order in all the architectures. > > The maximum page block order will be given by > > ARCH_FORCE_MAX_ORDER. > > > > By default, CONFIG_PAGE_BLOCK_ORDER will have the same > > value that ARCH_FORCE_MAX_ORDER. This will make sure that > > current kernel configurations won't be affected by this > > change. It is a opt-in change. > > > > This patch will allow to have the same CMA alignment > > requirements for large page sizes (16KiB, 64KiB) as that > > in 4kb kernels by setting a lower pageblock_order. > > > > Tests: > > > > - Verified that HugeTLB pages work when pageblock_order is 1, 7, 10 > > on 4k and 16k kernels. > > > > - Verified that Transparent Huge Pages work when pageblock_order > > is 1, 7, 10 on 4k and 16k kernels. > > > > - Verified that dma-buf heaps allocations work when pageblock_order > > is 1, 7, 10 on 4k and 16k kernels. > > > > Benchmarks: > > > > The benchmarks compare 16kb kernels with pageblock_order 10 and 7. The > > reason for the pageblock_order 7 is because this value makes the min > > CMA alignment requirement the same as that in 4kb kernels (2MB). > > > > - Perform 100K dma-buf heaps (/dev/dma_heap/system) allocations of > > SZ_8M, SZ_4M, SZ_2M, SZ_1M, SZ_64, SZ_8, SZ_4. Use simpleperf > > (https://developer.android.com/ndk/guides/simpleperf) to measure > > the # of instructions and page-faults on 16k kernels. > > The benchmark was executed 10 times. The averages are below: > > > > # instructions | #page-faults > > order 10 | order 7 | order 10 | order 7 > > -------------------------------------------------------- > > 13,891,765,770 | 11,425,777,314 | 220 | 217 > > 14,456,293,487 | 12,660,819,302 | 224 | 219 > > 13,924,261,018 | 13,243,970,736 | 217 | 221 > > 13,910,886,504 | 13,845,519,630 | 217 | 221 > > 14,388,071,190 | 13,498,583,098 | 223 | 224 > > 13,656,442,167 | 12,915,831,681 | 216 | 218 > > 13,300,268,343 | 12,930,484,776 | 222 | 218 > > 13,625,470,223 | 14,234,092,777 | 219 | 218 > > 13,508,964,965 | 13,432,689,094 | 225 | 219 > > 13,368,950,667 | 13,683,587,37 | 219 | 225 > > ------------------------------------------------------------------- > > 13,803,137,433 | 13,131,974,268 | 220 | 220 Averages > > > > There were 4.85% #instructions when order was 7, in comparison > > with order 10. > > > > 13,803,137,433 - 13,131,974,268 =3D -671,163,166 (-4.86%) > > > > The number of page faults in order 7 and 10 were the same. > > > > These results didn't show any significant regression when the > > pageblock_order is set to 7 on 16kb kernels. > > > > - Run speedometer 3.1 (https://browserbench.org/Speedometer3.1/) 5 time= s > > on the 16k kernels with pageblock_order 7 and 10. > > > > order 10 | order 7 | order 7 - order 10 | (order 7 - order 10) % > > ------------------------------------------------------------------- > > 15.8 | 16.4 | 0.6 | 3.80% > > 16.4 | 16.2 | -0.2 | -1.22% > > 16.6 | 16.3 | -0.3 | -1.81% > > 16.8 | 16.3 | -0.5 | -2.98% > > 16.6 | 16.8 | 0.2 | 1.20% > > ------------------------------------------------------------------- > > 16.44 16.4 -0.04 -0.24% Averages > > > > The results didn't show any significant regression when the > > pageblock_order is set to 7 on 16kb kernels. > > > > Cc: Andrew Morton > > Cc: Vlastimil Babka > > Cc: Liam R. Howlett > > Cc: Lorenzo Stoakes > > Cc: David Hildenbrand > > CC: Mike Rapoport > > Cc: Zi Yan > > Cc: Suren Baghdasaryan > > Cc: Minchan Kim > > Signed-off-by: Juan Yescas > > Acked-by: Zi Yan > > --- > > Changes in v4: > > - Set PAGE_BLOCK_ORDER in incluxe/linux/mmzone.h to > > validate that MAX_PAGE_ORDER >=3D PAGE_BLOCK_ORDER at > > compile time. > > - This change fixes the warning in: > > https://lore.kernel.org/oe-kbuild-all/202505091548.FuKO4b4v-lkp@inte= l.com/ > > > > Changes in v3: > > - Rename ARCH_FORCE_PAGE_BLOCK_ORDER to PAGE_BLOCK_ORDER > > as per Matthew's suggestion. > > - Update comments in pageblock-flags.h for pageblock_order > > value when THP or HugeTLB are not used. > > > > Changes in v2: > > - Add Zi's Acked-by tag. > > - Move ARCH_FORCE_PAGE_BLOCK_ORDER config to mm/Kconfig as > > per Zi and Matthew suggestion so it is available to > > all the architectures. > > - Set ARCH_FORCE_PAGE_BLOCK_ORDER to 10 by default when > > ARCH_FORCE_MAX_ORDER is not available. > > > > > > include/linux/mmzone.h | 16 ++++++++++++++++ > > include/linux/pageblock-flags.h | 8 ++++---- > > mm/Kconfig | 31 +++++++++++++++++++++++++++++++ > > 3 files changed, 51 insertions(+), 4 deletions(-) > > Hi Juan, > > The patch below on top of your v4 fixed powerpc build issue, as I tested > it locally. > > From 5c2ae4dfca135e99da45302e4f5d96a315a99603 Mon Sep 17 00:00:00 2001 > From: Zi Yan > Date: Sat, 17 May 2025 14:49:39 -0400 > Subject: [PATCH] fix CONFIG_PAGE_BLOCK_ORDER > > Signed-off-by: Zi Yan > --- > mm/Kconfig | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/mm/Kconfig b/mm/Kconfig > index 79237842f7e2..af0dd42e3506 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -1016,10 +1016,10 @@ config ARCH_FORCE_MAX_ORDER > # as per include/linux/mmzone.h. > config PAGE_BLOCK_ORDER > int "Page Block Order" > - range 1 10 if !ARCH_FORCE_MAX_ORDER > - default 10 if !ARCH_FORCE_MAX_ORDER > - range 1 ARCH_FORCE_MAX_ORDER if ARCH_FORCE_MAX_ORDER > - default ARCH_FORCE_MAX_ORDER if ARCH_FORCE_MAX_ORDER > + range 1 10 if ARCH_FORCE_MAX_ORDER =3D 0 > + default 10 if ARCH_FORCE_MAX_ORDER =3D 0 > + range 1 ARCH_FORCE_MAX_ORDER if ARCH_FORCE_MAX_ORDER !=3D 0 > + default ARCH_FORCE_MAX_ORDER if ARCH_FORCE_MAX_ORDER !=3D 0 > > help > The page block order refers to the power of two number of pages= that > -- > 2.47.2 > Thanks Zi, the changes were applied in v6 https://lore.kernel.org/all/20250520225945.991229-1-jyescas@google.com/ > > > > -- > Best Regards, > Yan, Zi