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 65AD2C02187 for ; Mon, 20 Jan 2025 00:17:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 77E046B0082; Sun, 19 Jan 2025 19:17:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 755436B0083; Sun, 19 Jan 2025 19:17:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5F4F66B0085; Sun, 19 Jan 2025 19:17:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 42AD86B0082 for ; Sun, 19 Jan 2025 19:17:47 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id D26411A2619 for ; Mon, 20 Jan 2025 00:17:46 +0000 (UTC) X-FDA: 83025916932.05.91780DB Received: from mail-vk1-f176.google.com (mail-vk1-f176.google.com [209.85.221.176]) by imf09.hostedemail.com (Postfix) with ESMTP id 10D94140007 for ; Mon, 20 Jan 2025 00:17:44 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=MKngVytp; spf=pass (imf09.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.176 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737332265; 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=oPPRZj16FrniFMp3D2wT43ikbht7lX+bIkR0fRkSADA=; b=734wLHngmw3EsggQCsOgESC7xS3zRg9BbQYtvd1X4A0XsDsBm2IfFni3qzD+SF9/hqkYbI WYqCyXOUFwiGFydHewN6jJ8ccV5Ud/Uph4Ioneeiw7wdWKJI8YtBvTrbUzwkdukmkUvPEG MnVg2QOjQQhdTrQXCYjaU36lNNOhNtU= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=MKngVytp; spf=pass (imf09.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.176 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737332265; a=rsa-sha256; cv=none; b=7+FrRCwBfmFSB28njSjEp1zXtUcxuTXXKleRYn/JjrbwgDbzzy/oW7atJ6jnUWNfGxV/hB VchG00sYANawbpeL1pRBhR8Us49gyvEANw2Is2acA1s5HP9MwLFggFkmWWe8tTBjpNWBYg X+NIiTWZ3DoN3KcfOCLEOcC6hn/PjBQ= Received: by mail-vk1-f176.google.com with SMTP id 71dfb90a1353d-518957b0533so1101509e0c.1 for ; Sun, 19 Jan 2025 16:17:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1737332264; x=1737937064; 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=oPPRZj16FrniFMp3D2wT43ikbht7lX+bIkR0fRkSADA=; b=MKngVytpYq7GUpTCYQdZzBfK7J7fsh2369oSu4g7rmHh8A41rr4RS+nRDl3zZ+vlWf G7VCHCIqAW9NGl3IFf1xj+Po16NkNJqthCJOACSAAMpMLgcdrbXE/Xr2pBc+aGZlZT9u txhVn9/VHzBAtb7NPuViViQLRJiGAUrrQsOFLcFxjcXIk38zd0zOTY6hHxmwOJ/7nLO/ F+T4z+oCghj+K01qmidmY6DjKAXimVVE0ca3kFjSnXP5mcDBaodl+cxxlLwR2Zpdaawe cRPgyZPBGMQn264bUh0jByUlo2j4YiWjaeiOTm8EGcRxSEpFVCoj54YbLsZnDPjyjpvu Bapg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737332264; x=1737937064; 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=oPPRZj16FrniFMp3D2wT43ikbht7lX+bIkR0fRkSADA=; b=WD+mdK20NdmXfdTeZLK/X/Rr1IDk6hSQ5M4fqStvrWebQEQuvDxHj6/v6KuuFXG4LB u7bnNcD5ma0Ev7rnTzlGzfvlxAB9fh2vyp2gXWmq2/o+tjOhnWChvl9V1of7iPaSd/Vb c1fxptVcLLGiqKiM2KMPec60HDEeo/WLCuII2yejpOKJ0NNvJvxbHMoTlhXhwGeWEnsR X71pyZ52oSUVQa5fR6HJaJhq4Iw8175BsFmA+5Qs3TM6yT653asvqJqtqjUr5sM5Jn59 9n9z8HndrIapPff2mr2tLStoUMc9786mTp9BkA9pm+jiHLtbMk6Ch693dzINd7sYMDH4 kj2A== X-Gm-Message-State: AOJu0YxRvIrSXQMKF213IaQAln2QJ0QV/e0noBO9J+RAUvE/4661iWys zp9K9BprBjeOvoSk9YkkKY94+u6IFGS3+ow2mYDhOOdZ0pClJiA+SjKOkq66B2E4ZuEMoMMCaj1 S8PYj2L3NZaioHTI1wK4G25hmaug= X-Gm-Gg: ASbGncvy1EBjND7nbryOwXWHNPswq1Z38LlUUjZue2UpFT+eGMq9RlyT7A4uep+YecD hUiCllpI3UQ/BCLbUuwcR8GrtrFkOw6JXngUNjGaxudKGcBFHJXcgTShYmrxCbCAQXjHx4OJ+W4 yONqJAM5yuoQ== X-Google-Smtp-Source: AGHT+IHqUjFsbYNoOXTiq/7lBjcg3LwI+fFEeN/BVbJTnWjiTpAppDUZAm4IQWJKJpd4y2hn6xizq46z232mAohJVFI= X-Received: by 2002:a05:6122:378a:b0:517:4d53:4272 with SMTP id 71dfb90a1353d-51d5b2e8e1dmr9088019e0c.7.1737332263885; Sun, 19 Jan 2025 16:17:43 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Mon, 20 Jan 2025 13:17:32 +1300 X-Gm-Features: AbW1kvYFntvOSkeNTDjNL--F5AHwbjgZti3FqwsWL62r6IRAw5Cha8kwCKAU-Oo Message-ID: Subject: Re: mm: CMA reservations require 32MiB alignment in 16KiB page size kernels instead of 8MiB in 4KiB page size kernel. To: Juan Yescas Cc: linux-mm@kvack.org, muchun.song@linux.dev, rppt@kernel.org, david@redhat.com, osalvador@suse.de, akpm@linux-foundation.org, lorenzo.stoakes@oracle.com, Jann Horn , Liam.Howlett@oracle.com, minchan@kernel.org, jaewon31.kim@samsung.com, charante@codeaurora.org, Suren Baghdasaryan , Kalesh Singh , "T.J. Mercier" , Isaac Manjarres , iamjoonsoo.kim@lge.com, quic_charante@quicinc.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 10D94140007 X-Stat-Signature: e1grx5uqqjh867o7ywgmozndb7awreh6 X-HE-Tag: 1737332264-40135 X-HE-Meta: U2FsdGVkX18t2FuuEr8VTOy9GRXVMbGIlQDPJHfXh3RfUm7hPAKX2UAzdn7cFF7tkcXF2NnlKlZ0A7/yL/68gsqiWsVJA1O8uA2HbsmRx8iadwHTVJ07Ud+x6zbntAgKqRKS9RFEI8XSivtqdQd6I+C0Ohz6o7lAMp4am8v7tjMS+tOCO72caatIKoedQMjXB7K34rxdHJE9PvFyKQlqw4YmqyUQPoeTzZZSPZrCd8W0Gh8WsXMk3Y50yy0mX1vTI/9jE6TPoNL46G7uVtEx6Pg4JYF/zSKePvTNtYI8Frg14H/3rYvxlTlmWceHUrM9hU9XW8m+yKm0aildy0B3ptsh199QMsqiG3p493qMKnIiDvlGnUa41TWCg7V2LjtMDoyyJrq5KDpFlgTuyN7iVX0BNoIm+ZngbVLfmfPGXKnl9PeJ7GtbQ7z1Wxt2yUm4mRFUzclSZg1wXpPo82sW0gl4FvR6iEfTpBv5kppGFfxvnq/gmHnK7aThwXyPqZtFjwHzTIbdFbH6hqrLk25mYZPaxvAyO6LcSFoQAsngBeqbQclWXrIU2JzuhtsIOXYs+beq7+dl2itdenA9p3Kby914zDr1tKs5MxIVu40Q/C/IHbKnvtsIui6xqMk2zZefAv78BwQCSkh9MOduE5FrrvZoNayk9FdPiD3whcbizlqHadT3fKeLrYIa82eBKV0ot4RSCXq7dBZ52GpHVBrG2Aw1hISW2NtT4Q/spySF6g4LEbvQbW1Xx1e+gxqyacoTdargrqcyIyePmE1VKRkkxzjIvohSsW7YnuxcOqSNBoXO9/Rz7NVoRemNOoo/qCvP1eCxFT0XUggQpIohMGD100/K3o9c1BEPL+Wg6cvAAH2UK79LJotGq2n991RI9kCWzWc3qlciEZRyvJW2IExkzahu2tEtiVBTnm5a9iCac155u5DdVnFILBpn8713sugBCK3tPdkDarAWoXqvqeU 2l/3GxEK K/7Djbw0rovGjR3jYuZ0QyIVkjEMtucyW4etvZNJzrTBeWMdkUOf6gQ4N/GgLNssGRM2IlZzC8sPb5iJTsv5F53NjiLhqiufWx2jftnmGXX0jwYd+Y6UX2PvayWMKcIK49Qc9BG9sRzhK0w7gHRgnHXMOqFC1H0y1LHsCeVkOz1sLRabpwpFLn7gsQlsTiKwSoG9CfTydP2ZHion2BLc/SW+dWVp5VyXHjVuC0G4wOyIAiglTaJlR40oPN1HBc126Oyqc5uvOoKV/mSOipK5uwgo3ja6Aj5VUHqBSm5+7rnpwr/t4b5LK9GTJx1jFkX2KC54R5WZg2pyyxdbIErgTHJfaqzn/tWcfpXJNHZDHlUX8hXDvWhV2k8hEMFTnxd6Wu18WMWSgisp7xqT+pGt+QlWjxHhMaiH7RgjBYvVfL1c4ivo= X-Bogosity: Ham, tests=bogofilter, spamicity=0.003780, 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, Jan 18, 2025 at 12:00=E2=80=AFPM Juan Yescas w= rote: > > + iamjoonsoo.kim@lge.com > + quic_charante@quicinc.com > > On Fri, Jan 17, 2025 at 2:52=E2=80=AFPM Juan Yescas = wrote: > > > > +Suren Baghdasaryan > > +Kalesh Singh > > +T.J. Mercier > > +Isaac Manjarres > > > > On Fri, Jan 17, 2025 at 2:51=E2=80=AFPM Juan Yescas wrote: > > > > > > Hi Linux memory team > > > > > > When the drivers reserve CMA memory in 16KiB kernels, the minimum > > > alignment is 32 MiB as per CMA_MIN_ALIGNMENT_BYTES. However, in 4KiB > > > kernels, the CMA alignment is 4MiB. > > > > > > This is forcing the drivers to reserve more memory in 16KiB kernels, > > > even if they only require 4MiB or 8MiB. > > > > > > reserved-memory { > > > #address-cells =3D <2>; > > > #size-cells =3D <2>; > > > ranges; > > > tpu_cma_reserve: tpu_cma_reserve { > > > compatible =3D "shared-dma-pool"; > > > reusable; > > > size =3D <0x0 0x2000000>; /* 32 MiB */ > > > } > > > > > > One workaround to continue using 4MiB alignment is: > > > > > > - Disable CONFIG_TRANSPARENT_HUGEPAGE so the buddy allocator does NOT > > > have to allocate huge pages (32 MiB in 16KiB page sizes) > > > - Set ARCH_FORCE_MAX_ORDER for ARM64_16K_PAGES to "8", instead of > > > "11", so CMA_MIN_ALIGNMENT_BYTES is equals to 4 MiB > > > > > > config ARCH_FORCE_MAX_ORDER > > > int > > > default "13" if ARM64_64K_PAGES > > > default "8" if ARM64_16K_PAGES > > > default "10" > > > > > > #define MAX_PAGE_ORDER CONFIG_ARCH_FORCE_MAX_ORDER // 8 > > > #define pageblock_order MAX_PAGE_ORDER // 8 > > > #define pageblock_nr_pages (1UL << pageblock_order) // 256 > > > #define CMA_MIN_ALIGNMENT_PAGES pageblock_nr_pages // 256 > > > #define CMA_MIN_ALIGNMENT_BYTES (PAGE_SIZE * CMA_MIN_ALIGNMENT_PAGES) > > > // 16384 * 256 =3D 4194304 =3D 4 MiB > > > > > > After compiling the kernel with this changes, the kernel boots withou= t > > > warnings and the memory is reserved: > > > > > > [ 0.000000] Reserved memory: created CMA memory pool at > > > 0x000000007f800000, size 8 MiB > > > [ 0.000000] OF: reserved mem: initialized node tpu_cma_reserve, > > > compatible id shared-dma-pool > > > [ 0.000000] OF: reserved mem: > > > 0x000000007f800000..0x000000007fffffff (8192 KiB) map reusable > > > tpu_cma_reserve > > > > > > # uname -a > > > Linux buildroot 6.12.9-dirty > > > # zcat /proc/config.gz | grep ARM64_16K > > > CONFIG_ARM64_16K_PAGES=3Dy > > > # zcat /proc/config.gz | grep TRANSPARENT_HUGE > > > CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=3Dy > > > # CONFIG_TRANSPARENT_HUGEPAGE is not set > > > # cat /proc/pagetypeinfo > > > Page block order: 8 > > > Pages per block: 256 > > > > > > Free pages count per migrate type at order 0 1 2 > > > 3 4 5 6 7 8 > > > Node 0, zone DMA, type Unmovable 1 1 13 > > > 6 5 2 0 0 1 > > > Node 0, zone DMA, type Movable 9 16 19 > > > 13 13 5 2 0 182 > > > Node 0, zone DMA, type Reclaimable 0 1 0 > > > 1 1 0 0 1 0 > > > Node 0, zone DMA, type HighAtomic 0 0 0 > > > 0 0 0 0 0 0 > > > Node 0, zone DMA, type CMA 1 0 0 > > > 0 0 0 0 0 49 > > > Node 0, zone DMA, type Isolate 0 0 0 > > > 0 0 0 0 0 0 > > > Number of blocks type Unmovable Movable Reclaimable > > > HighAtomic CMA Isolate > > > Node 0, zone DMA 6 199 1 > > > 0 50 0 > > > > > > > > > However, with this workaround, we can't use transparent huge pages. I don=E2=80=99t think this is accurate. You can still use mTHP with a size equal to or smaller than 4MiB, right? By the way, what specific regression have you observed when reserving a larger size like 32MB? For CMA, the over-reserved memory is still available to the system for movable folios. 28MiB doesn=E2=80=99t seem significant enough to cause a noticeable regression, d= oes it? > > > > > > Is the CMA_MIN_ALIGNMENT_BYTES requirement alignment only to support = huge pages? > > > Is there another option to reduce the CMA_MIN_ALIGNMENT_BYTES alignme= nt? > > > > > > Thanks > > > Juan Thanks barry