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 C339FC5AE59 for ; Tue, 3 Jun 2025 15:14:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4D0656B02F0; Tue, 3 Jun 2025 11:14:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 479D76B04A8; Tue, 3 Jun 2025 11:14:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2F4256B04A9; Tue, 3 Jun 2025 11:14:45 -0400 (EDT) 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 08EFF6B04A6 for ; Tue, 3 Jun 2025 11:14:45 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 9D8FEC0D99 for ; Tue, 3 Jun 2025 15:14:44 +0000 (UTC) X-FDA: 83514436488.22.2D9EBEB Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2056.outbound.protection.outlook.com [40.107.244.56]) by imf12.hostedemail.com (Postfix) with ESMTP id 9B87B40003 for ; Tue, 3 Jun 2025 15:14:41 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=Nvidia.com header.s=selector2 header.b=ORnQ7LjI; spf=pass (imf12.hostedemail.com: domain of ziy@nvidia.com designates 40.107.244.56 as permitted sender) smtp.mailfrom=ziy@nvidia.com; dmarc=pass (policy=reject) header.from=nvidia.com; arc=pass ("microsoft.com:s=arcselector10001:i=1") ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748963681; 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=iT1QA1kT9enUTpfMtTCZNUrLxO+HYqvKZa4G71y1h3E=; b=sOjQzHp3Chxja7iLKcO9gpn0BbbXol2kPmIrmGm7yKT+/lTk24E8IJ8ShEz7WPziImD6t6 OJ8k8YoX8xx2sfwwPpBfkFkhgKd8zE0hhsCmP5iV6lcQlofqHgO+zcglWAk7olnzSwUN4Z b2fhYrtN0k0T8fOQ87CSkrq+Cp6GHSI= ARC-Authentication-Results: i=2; imf12.hostedemail.com; dkim=pass header.d=Nvidia.com header.s=selector2 header.b=ORnQ7LjI; spf=pass (imf12.hostedemail.com: domain of ziy@nvidia.com designates 40.107.244.56 as permitted sender) smtp.mailfrom=ziy@nvidia.com; dmarc=pass (policy=reject) header.from=nvidia.com; arc=pass ("microsoft.com:s=arcselector10001:i=1") ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1748963681; a=rsa-sha256; cv=pass; b=P4AeBs4PiI0nKiqVkiADF5hVsnjtw+JqZPMR3putI6joFlTZKzPN/di6FD8e863Qmp5yrN AETq9L0cqSGw+pfHCe4Jh3juMsvEWKix2hfYInAqQkEjybtIl36c3mj84sAr1HqFO3v/xo UAHCzqK+hdmaFYYqvjEVuOJjIa8vfig= ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=rLanlz/3Xw52yZdj0t+QvkdsxUuHJjOVQoM87pZ3T6fkMGDQSPPA26frsdzxL+mIVu7kPBtx+F5gxNRqVMaNE5QQidlNWfONUqBrMJC15wbwT0wm7eEfdDOUV5fNkpjzevzAWIDqG15ol3Z3b1D5EIjnGlI2bDZIQnXHrzesIurbOxyuCYVYdU2ySKSH3H4r90xbkbnRaNjOoiDyXBzSYXoXuVb4RUmzhdW0jb8K46yRPYgxUmcKPtyAi0prW52JgaDuw/SmHpOLzx+F68fVM77VmNi+zY3z98WdUaGu/hB12FzGeELPjzSSU816dWJqZFEh4+uEx1VJ/AYekyIrJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=iT1QA1kT9enUTpfMtTCZNUrLxO+HYqvKZa4G71y1h3E=; b=Xz3AVt12E/CzMofv6B90iQXJeEv7vhljm2fiTEjFzsUf0NsEbAIOmx+54I4LEWfE91N1FYckVnLRX2gA3HtMwmfuG0LWej2YPgiITSvZ4J4ltGUWjHGnhADQGW2idd4if4cUlQDfOnHfCi4+b0+F9xby5bTyAx1RWLU3bBVWZ1faWCynAB2Kp0amGhQ2+2U3t4CQgbundp+KKtrmc2PyFT5yUToQy9MA4FoOAuJxaUGmJui+49GBFlv10KvD+1/RvR1yjfMOslkFzFPvknPMVSQkfO7muY7ghSZPK7wdcgQc8cdWl5J9cjjPUKLapWEoOXeQsNd7U35whytOl3elrg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iT1QA1kT9enUTpfMtTCZNUrLxO+HYqvKZa4G71y1h3E=; b=ORnQ7LjIGC9aU/3IRLK5KStm7m+55CQdwZ5O+rd1l6A2Otv0nIIQwMrzAaNX3LRjqqAoxoRi2f+2eldyMWvWM+vu8ptC33/1/UnNsMSy4aPoi5GKfb5RtLd6Uum8M/4Ol9XQsDx6o+98Duh1j9+X1Atwi0cmLUbhb68NoeN5xi48kdwsEzRe4GkpyJS4wtvtPh/bZC5fW4/b1OyvzJIkZwnc7M1ECCEGET+kD/31vUEssS1IgZDY3c/pcYwqpcW7BUCOsDZfQpNdPCLOwd7B8H/6g26N0K0GwzEKq4cZavvykzhLx/Gl4kuGJFKPa4XfE5UBXEoHI77tD7zrE4yB0g== Received: from DS7PR12MB9473.namprd12.prod.outlook.com (2603:10b6:8:252::5) by IA0PR12MB8278.namprd12.prod.outlook.com (2603:10b6:208:3dc::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8792.33; Tue, 3 Jun 2025 15:14:36 +0000 Received: from DS7PR12MB9473.namprd12.prod.outlook.com ([fe80::5189:ecec:d84a:133a]) by DS7PR12MB9473.namprd12.prod.outlook.com ([fe80::5189:ecec:d84a:133a%5]) with mapi id 15.20.8792.034; Tue, 3 Jun 2025 15:14:36 +0000 From: Zi Yan To: David Hildenbrand Cc: Juan Yescas , Andrew Morton , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , , , , , , , Minchan Kim Subject: Re: [PATCH v7] mm: Add CONFIG_PAGE_BLOCK_ORDER to select page block order Date: Tue, 03 Jun 2025 11:14:33 -0400 X-Mailer: MailMate (2.0r6255) Message-ID: <74955261-748E-4E91-8D55-6ECAEBFB3F70@nvidia.com> In-Reply-To: <51739EAE-32CB-43AD-A969-B24FE3DAA351@nvidia.com> References: <20250521215807.1860663-1-jyescas@google.com> <54943dbb-45fe-4b69-a6a8-96381304a268@redhat.com> <51739EAE-32CB-43AD-A969-B24FE3DAA351@nvidia.com> Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: MN2PR20CA0057.namprd20.prod.outlook.com (2603:10b6:208:235::26) To DS7PR12MB9473.namprd12.prod.outlook.com (2603:10b6:8:252::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS7PR12MB9473:EE_|IA0PR12MB8278:EE_ X-MS-Office365-Filtering-Correlation-Id: 02957049-3e1a-47f7-9227-08dda2b159fe X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|366016|1800799024; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?7yLSweik7BizBvx8riJoziqefpGeCQyo6/eGH2n85aFtMeDhcbBw66uaxSNI?= =?us-ascii?Q?4AI3lzgIlux81IRpoITrF5cldCJ4cFO5RgxUm/t6zGCTRb04Sgiq2VT7QjGJ?= =?us-ascii?Q?ibnHIjof4+odsp/MB6qxFLKDSCI48NtLZBuOOe6UjG1bySKidMU3BekcLNav?= =?us-ascii?Q?PfBj37feQDh+HJK9hCUQUjppyZPDRpf24L3MkQu1hjrfQLrXnQJ+4TtzpcqA?= =?us-ascii?Q?yOYwXfFk6Kmm2IDFJkWlls/AbQa54+Arvvd/d8nwMuidzUkt5nLaU3A+JZtV?= =?us-ascii?Q?gudWZ7vCoOsXLe4mYxy9aKDigjCqN8tYXKlFn+AWV/OQHXs2S47Y5YNuM2LA?= =?us-ascii?Q?NWy5H4ik4R3+wIu1sD+t7advJXm9GQs19TDLTp5W/M519cAfANVPydSxAZF+?= =?us-ascii?Q?+XQPcnge18UERZHT7+f7lRAGUMUGOyXzmUBWjGWs9iLsy7kpMU2m5UAcMgaZ?= =?us-ascii?Q?8lDvle3XSuldlcdh3gqvTsTuLYe/yoQqgeeGJgK/jirtbt8biVxQPJ0MBcch?= =?us-ascii?Q?tB+SdeQ2Vus6Gkfag57Aqr6SVjrIPxwuGWGcK5IoKKpvZzlnM8wOkEN8oc/V?= =?us-ascii?Q?WoPThCS9Bo4Y2lz5clSuxzownly9uFI60CPO858N2gCNEK/GLXRcjIrCw+jG?= =?us-ascii?Q?znjdZVlmdAL1yM3pNPhSH/qz6bJ9NiJEoX1HCSpoEePoPL4KPurnaM2KJL60?= =?us-ascii?Q?cLQiSrzDKSTFfdrSFuMzMyeiw4VWWLtwEPg9s+D4klVwMn+VZ1MrZaseP2AM?= =?us-ascii?Q?mJ0i2l8m6tznj5D4UiEs8yjGpJGE83hWWCSzQkSsjMdiTlVAPjPB9GkUQR46?= =?us-ascii?Q?OcTv2yS7TUgJHkCaWPfmGV5nVEcOSkOrCXf6pvuWjDswIqYsxQzty0M54WFe?= =?us-ascii?Q?bmoWfHC6KMxk2p47qHRcBqSsK6MaKRX6nJ947qmM2RDGr5VxnyR7yDPqI6g1?= =?us-ascii?Q?/nNFamBxxXBzTTIdw4QZMbrZ51CZxAmSeVkpK52pqjuoKptRFEQKBiiagylW?= =?us-ascii?Q?rz14gdSviDN2JTeRFVfWL9g9EKZcaTSWZQBULYAZiR1zoMljXZhMcMKa6LI/?= =?us-ascii?Q?op42W36AMxy4y0A0OEcndDgbUjR1kTZOfevQ1xupDUyvmAEgn5Hl4TbVwExD?= =?us-ascii?Q?/ZpR6asbT1izsYQDSx4CWNG/K/PKATsYazErIbRZnGE5bA3yhfkdCCgWergj?= =?us-ascii?Q?tDisMQH3P5Nv57HDLlpTahrPxfP5oGFeUbwocaeGjYcis0OjlmI/MuNdE/G3?= =?us-ascii?Q?XE5Y9XFiNp9JuBzZ3NebNrwVnDBqmkkz15mmyaHFghMpMKnCVZN909SOgK20?= =?us-ascii?Q?Mda/QdPTl6l4qER5pLhCxw+5OT+imtH47WhQAr0i3ZYCIKOWA4/Y5j+Ddggc?= =?us-ascii?Q?I4JlLsMEFaLUB4GwrknjxecLL0KZgXkSDSmq5MGdLfurHO7Ev7zBZgqYFcIf?= =?us-ascii?Q?ZV1tmrUeHWI=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS7PR12MB9473.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?+3hFK72uTd9VGtkWHqG0hl9s5weFP7wN0bxodBaNJPkulqDF4otPqyWK4b3g?= =?us-ascii?Q?vOkJC0qRr0gXYmmHxzFJFfWszQ/D3LANFqHr9nEnxeTaggagV+kX8TalO17z?= =?us-ascii?Q?LOY0OTrvdQmyk5UGo3Y6jPmEVTqejyBhfXN6fbkFSZwi24uYtdaPsJrq/1LA?= =?us-ascii?Q?3xG6IQypiF4CAdY/92CbcWeNseya9k2eesUC4//QIwSnveKgi5ZUkMjmtf5/?= =?us-ascii?Q?xFV5enQCvfMWdmh88tbcpZDP7I4ZoY2mDOw9lusfVhMdN+qayxhamOWHiinf?= =?us-ascii?Q?IffgQOqVgJTgd5KwqKyJ+kRR+eOcRE84jV7cRNO7k51OEt/gcgdUohdXC7qK?= =?us-ascii?Q?q2sGDo1LV+8pdkbMyt0aSOOW61Ckg4fQWs4AMtrR2UhdKt2vPC5kcUkdlOBF?= =?us-ascii?Q?W+3Kptm77pzA9Y6OJLgpsJio5qG70yoPTCU7XBaA2LacPbm3SRGx+IxP5ZZq?= =?us-ascii?Q?jx3flI4z4cga/YOGfd4k0lgm7HdnnCD6IIpovu1uKg7nVJBoNu9mYmNjio+L?= =?us-ascii?Q?gU4ZLEaxDSE4Xb8IWAJx8vJQ2t9Jh+wjmNQaw585BK10lsuFPoqbSCQbBO0N?= =?us-ascii?Q?Qqm6QPwRs2EEDNr20bxFN23YRlZmn1tRQ6O72KaH07VTg3QDJsMqhfslQeV2?= =?us-ascii?Q?jLa/YD48ugKIKS9qIguJgqm5eXrI1rt+ta+PuRu3xf5+2E3LEMSKMzN7qYfU?= =?us-ascii?Q?tD01q9XU3YS9rHucv7FXP8mSuZnDYyxTS376DFS7IVKD+nuzBZZAwMa/QFFN?= =?us-ascii?Q?XAjKiTOIWoFWpsNTNNfHlIWxP4ab/RJE6oWy9N7f3w1WKUvbkx8tajpRkwnb?= =?us-ascii?Q?XLoEXtoRuoQESuv0h0LgY88W5ZhOEncrLvsbpF0yYmeZICOXL2zAmSJyfv8b?= =?us-ascii?Q?GOKHcogTvgNKthWym12ccNzyhzj6Mtf9B5xbmPkAXamkAmIZTdRePlWl3TLU?= =?us-ascii?Q?FBlQX0iRvolXsKepvL+SwLEzqvyVipM4mdKTaQ42U+VcHU74H/kSE7K2nhdI?= =?us-ascii?Q?Qb8BpPozvQroPLHbUwmvA9HUsSsN93UanlYIoHjNQ2Q7ahXNqJgfQM8tpFUs?= =?us-ascii?Q?aNr+E9ZeeYCQK8NIpLARu4lAXatr0nB9IYmBsgQQN2MwctCwC3Ks0XItmNbE?= =?us-ascii?Q?DybMok8EOBhFKeKmTHQX6FqR+viIjwhoPU4ARidnXUDYktgo43MdYHlEEGAR?= =?us-ascii?Q?BhbpC2kkb7d2bYaPA1csxVMtftPWW5iXn5LQZefK+O3xgxIyJ1ibWeNILhtg?= =?us-ascii?Q?e/u/VHaizl+kZ42a69qEmh+O267UjOiiiayQZLI67wX+w2+/FiuT+Wk3Ocr3?= =?us-ascii?Q?nvtISQb2s2KUt2/nNlYvQjdsYXILD/jGsl2oQqKuc0id5beH3AVIpYKztBFm?= =?us-ascii?Q?jXn9swp23Tida1VTr+AGUIcPOQQtMt1Ozj/bSioIscEIWihrYQd+T/BSdozH?= =?us-ascii?Q?9woZR2/qUl8adcZryGPAYBxqHi5SDpF3Ody9yOpQa6U7NMF0iT5+V5EsgeUD?= =?us-ascii?Q?q5/GiSgTVmquYq1Nr68oT5jJJ76QLSVQ2Y6I84095YWlTq4tDzAxvjGxuFQ0?= =?us-ascii?Q?IMt+3fsvcNv7ZXMb8hGclWSyrtp9NZdp8AMtMKFq?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 02957049-3e1a-47f7-9227-08dda2b159fe X-MS-Exchange-CrossTenant-AuthSource: DS7PR12MB9473.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jun 2025 15:14:36.0836 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: rJaihGA4xAGZsjuchh96oKgiQ/vdKnzMGkz0WyLBqXy02PN//bZsD/s/RK1Q2WtB X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB8278 X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 9B87B40003 X-Stat-Signature: imgyp6bwg1ffmn8kqcd9r7scw4fjc1bh X-Rspam-User: X-HE-Tag: 1748963681-583696 X-HE-Meta: U2FsdGVkX1+Mv+5/EPRSrG41KUK/49UdbFXKGxqbBjc5KvcidsSqh6EPNIyC/fCTt4Ks5BEXiCq80CIVbNTetxjiC50mN/M9KdnVL7UcACCJ0oIKQ4ZTCj2XuW2lGClUW6MzN6D1N6INhwjWtpmVm04hUddmmYwewcG0msE/J7Uad38JpUA+qQwrWmF+AJzxhMsOokqEEzYBvtvQrm3aazXIcmaqE+jNIROUbk28u0BWo/cQ1LbsX+f2hpIVEgvHPt+/Wl9tDowCPSAfy5ySE+oNTSmSDMVjREGXhdsSzGrjDuJXnihRvNf0jlztXi3LZ2QNC+7hKfYoAYr/zENzyODM15mhrZ0gC4ZleVVsqdX0Po8vXgooM1EkXYA3rd+I2f6YtxhxF0vNbHmfCffenxUjuyJYQeQp2zduSxXPyE+42kKpWCwmIOC2Doc2HOxNpgTYdaeiqnDkYrT6J8RBcGgdkb1FYZ9CeWVckTxOHBuoWZ99LjX7nGfVoL25ev7o+rU73YnBCIDm1OxruFWo5H7UpEgPVVh9QxoCkau6EdMQeEJpQvpuIR/ggW4S6rULCD5whG+LS38kBq2CPtnE4Jb+o//DdDfPOkr29n1oRsvsggyb3idCt9kC9eGkCwisf4ib2InD41mniB31PHCEb4a3sNHBCEW+VEBIZtwTUrEYXjTPkmIYdqTypzCtSbgxnHQaVLgXq/WHHp6PDTdgXucUteuUFk530B4t5qzm4LEbdlB/8tB1vQfwEafSxPLdSbZXhDgTeLhUPr8mlQgWO3afdfFMy2Y+eDdZbBeU7KRhKY+dK0ONRyKk6LaPKgblfjgVgaRlY2M//9U8cLjifzlcRRFe5yOCoZKBQez7XyzWTvFe4v7EtDPhRBXX7O+9a9/vRw18RXq++kIjepasEKF4gY/PuIrmWqRtk39Hf9gvDhBVHMeWi7NqyR0g8KrQD/RM1L8rhOik5TXVUBn Z4+MKVFs amCWHqP+Q878qFDVSmtwxYW4euYIRFWvYa+JtPYQFQ8YAa2Gqzn+37zXiJUd3N0+WcWLqeCTT1oApjelzBf79xdCHnrMx7npIa+5BHvzo9V+6a7+5mHXXL8/miZqvIUPtZRrKGjdScqA7ItcwRMhOYpbLTBxQCwm33eX17uPEHW+JUvsPUdSNF7AcrZfhzbVYpuQOoxV4Hvbtw1sAFC3FghP3It4pMReCt3kE43CfEmKIHk9x25SIkSLk+vpnX+6NevuSMpuSe5wskk2J7hPXdAvQG/vuKgKG0XcGfM1GUFx+v0J+WdIaD3EDebwZ/o37qRaBjcesyc6x6CmgRUog0/dW5WSef8o0gRej+fUhEC1U5K4bArThXxcy+oG8Er789w+cQSLbz817pvN3OT8+rb7ZCjO7Cx4ditjpAzcSkQ7Z5LTNIUSlgSDZKYtf73BRbxI1iTrw/U6Jf7MgNlkwX5ijNhChNj579YvTXxhQtVrmifA3fgex52lZvPlI3q2XLIg3AnAEZzPX17E4nR334IZmXzUFGie/IE0zKBYGdiBZpP7lQfSKarGraVcvnonKoKhUoQlgnTyJP5tVRkIn2pm1p3Yjf79tXOqjXJP9WhpE9O0N7PFxsaJhHIocw/6SWHcIccYVGGz730RtjRDAurJvvN0D8A8vww59OWkjCjBIgYO0xuUUMtgNnJjn0xy7TLLLZGc6YWCMMrJL/aI8nUyWsPc389WapYFs05ewcLJgWEY= 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 3 Jun 2025, at 10:55, Zi Yan wrote: > On 3 Jun 2025, at 9:03, David Hildenbrand wrote: > >> On 21.05.25 23:57, Juan Yescas wrote: >>> Problem: On large page size configurations (16KiB, 64KiB), the CMA >>> alignment requirement (CMA_MIN_ALIGNMENT_BYTES) increases considerabl= y, >>> 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 t= hem. >>> >>> 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_BYTE= S >>> ---------------------------------------------------------------------= -- >>> 4KiB | 10 | 9 | 4KiB * (2 ^ 9) =3D = 2MiB >>> 16Kib | 11 | 11 | 16KiB * (2 ^ 11) =3D = 32MiB >>> 64KiB | 13 | 13 | 64KiB * (2 ^ 13) =3D = 512MiB >>> >>> 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_BYT= ES >>> ---------------------------------------------------------------------= --- >>> 4KiB | 15 | 15 | 4KiB * (2 ^ 15) =3D = 128MiB >>> 16Kib | 13 | 13 | 16KiB * (2 ^ 13) =3D = 128MiB >>> 64KiB | 13 | 13 | 64KiB * (2 ^ 13) =3D = 512MiB >>> >>> 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. Th= e >>> 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 ti= mes >>> 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 v7: >>> - Update alignment calculation to 2MiB as per David's >>> observation. >>> - Update page block order calculation in mm/mm_init.c for >>> powerpc when CONFIG_HUGETLB_PAGE_SIZE_VARIABLE is set. >>> >>> Changes in v6: >>> - Applied the change provided by Zi Yan to fix >>> the Kconfig. The change consists in evaluating >>> to true or false in the if expression for range: >>> range 1 if . >>> >>> Changes in v5: >>> - Remove the ranges for CONFIG_PAGE_BLOCK_ORDER. The >>> ranges with config definitions don't work in Kconfig, >>> for example (range 1 MY_CONFIG). >>> - Add PAGE_BLOCK_ORDER_MANUAL config for the >>> page block order number. The default value was not >>> defined. >>> - Fix typos reported by Andrew. >>> - Test default configs in powerpc. >>> >>> 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@in= tel.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 | 34 ++++++++++++++++++++++++++++++= +++ >>> mm/mm_init.c | 2 +- >>> 4 files changed, 55 insertions(+), 5 deletions(-) >>> >>> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h >>> index 6ccec1bf2896..05610337bbb6 100644 >>> --- a/include/linux/mmzone.h >>> +++ b/include/linux/mmzone.h >>> @@ -37,6 +37,22 @@ >>> #define NR_PAGE_ORDERS (MAX_PAGE_ORDER + 1) >>> +/* Defines the order for the number of pages that have a migrate ty= pe. */ >>> +#ifndef CONFIG_PAGE_BLOCK_ORDER >>> +#define PAGE_BLOCK_ORDER MAX_PAGE_ORDER >>> +#else >>> +#define PAGE_BLOCK_ORDER CONFIG_PAGE_BLOCK_ORDER >>> +#endif /* CONFIG_PAGE_BLOCK_ORDER */ >>> + >>> +/* >>> + * The MAX_PAGE_ORDER, which defines the max order of pages to be al= located >>> + * by the buddy allocator, has to be larger or equal to the PAGE_BLO= CK_ORDER, >>> + * which defines the order for the number of pages that can have a m= igrate type >>> + */ >>> +#if (PAGE_BLOCK_ORDER > MAX_PAGE_ORDER) >>> +#error MAX_PAGE_ORDER must be >=3D PAGE_BLOCK_ORDER >>> +#endif >>> + >>> /* >>> * PAGE_ALLOC_COSTLY_ORDER is the order at which allocations are de= emed >>> * costly to service. That is between allocation orders which shou= ld >>> diff --git a/include/linux/pageblock-flags.h b/include/linux/pagebloc= k-flags.h >>> index fc6b9c87cb0a..e73a4292ef02 100644 >>> --- a/include/linux/pageblock-flags.h >>> +++ b/include/linux/pageblock-flags.h >>> @@ -41,18 +41,18 @@ extern unsigned int pageblock_order; >>> * Huge pages are a constant size, but don't exceed the maximum all= ocation >>> * granularity. >>> */ >>> -#define pageblock_order MIN_T(unsigned int, HUGETLB_PAGE_ORDER, MAX= _PAGE_ORDER) >>> +#define pageblock_order MIN_T(unsigned int, HUGETLB_PAGE_ORDER, PAG= E_BLOCK_ORDER) >>> #endif /* CONFIG_HUGETLB_PAGE_SIZE_VARIABLE */ >>> #elif defined(CONFIG_TRANSPARENT_HUGEPAGE) >>> -#define pageblock_order MIN_T(unsigned int, HPAGE_PMD_ORDER, MAX_P= AGE_ORDER) >>> +#define pageblock_order MIN_T(unsigned int, HPAGE_PMD_ORDER, PAGE_B= LOCK_ORDER) >>> #else /* CONFIG_TRANSPARENT_HUGEPAGE */ >>> -/* If huge pages are not used, group by MAX_ORDER_NR_PAGES */ >>> -#define pageblock_order MAX_PAGE_ORDER >>> +/* If huge pages are not used, group by PAGE_BLOCK_ORDER */ >>> +#define pageblock_order PAGE_BLOCK_ORDER >>> #endif /* CONFIG_HUGETLB_PAGE */ >>> diff --git a/mm/Kconfig b/mm/Kconfig >>> index e113f713b493..13a5c4f6e6b6 100644 >>> --- a/mm/Kconfig >>> +++ b/mm/Kconfig >>> @@ -989,6 +989,40 @@ config CMA_AREAS >>> If unsure, leave the default value "8" in UMA and "20" in NUMA.= >>> +# >>> +# Select this config option from the architecture Kconfig, if availa= ble, to set >>> +# the max page order for physically contiguous allocations. >>> +# >>> +config ARCH_FORCE_MAX_ORDER >>> + int >>> + >>> +# >>> +# When ARCH_FORCE_MAX_ORDER is not defined, >>> +# the default page block order is MAX_PAGE_ORDER (10) as per >>> +# include/linux/mmzone.h. >>> +# >>> +config PAGE_BLOCK_ORDER >>> + int "Page Block 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 t= hat >>> + are physically contiguous and can have a migrate type associated = to >>> + them. The maximum size of the page block order is limited by >>> + ARCH_FORCE_MAX_ORDER. >>> + >>> + This config allows overriding the default page block order when t= he >>> + page block order is required to be smaller than ARCH_FORCE_MAX_OR= DER >>> + or MAX_PAGE_ORDER. >>> + >>> + Reducing pageblock order can negatively impact THP generation >>> + success rate. If your workloads uses THP heavily, please use this= >>> + option with caution. >>> + >>> + Don't change if unsure. >> >> >> The semantics are now very confusing [1]. The default in x86-64 will b= e 10, so we'll have >> >> CONFIG_PAGE_BLOCK_ORDER=3D10 >> >> >> But then, we'll do this >> >> #define pageblock_order MIN_T(unsigned int, HPAGE_PMD_ORDER, PAGE_BLOC= K_ORDER) >> >> >> So the actual pageblock order will be different than CONFIG_PAGE_BLOCK= _ORDER. >> >> Confusing. >> >> Either CONFIG_PAGE_BLOCK_ORDER is misnamed (CONFIG_PAGE_BLOCK_ORDER_CE= IL ? CONFIG_PAGE_BLOCK_ORDER_LIMIT ?), or the semantics should be changed= =2E > > IIRC, Juan's intention is to limit/lower pageblock order to reduce CMA = region > size. CONFIG_PAGE_BLOCK_ORDER_LIMIT sounds reasonable to me. LIMIT might be still ambiguous, since it can be lower limit or upper limi= t. CONFIG_PAGE_BLOCK_ORDER_CEIL is better. Here is the patch I come up with,= if it looks good to you, I can send it out properly. =46rom 7fff4fd87ed3aa160db8d2f0d9e5b219321df4f9 Mon Sep 17 00:00:00 2001 From: Zi Yan Date: Tue, 3 Jun 2025 11:09:37 -0400 Subject: [PATCH] mm: rename CONFIG_PAGE_BLOCK_ORDER to CONFIG_PAGE_BLOCK_ORDER_CEIL. The config is in fact an additional upper limit of pageblock_order, so rename it to avoid confusion. Signed-off-by: Zi Yan --- include/linux/mmzone.h | 14 +++++++------- include/linux/pageblock-flags.h | 8 ++++---- mm/Kconfig | 15 ++++++++------- 3 files changed, 19 insertions(+), 18 deletions(-) diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h index 283913d42d7b..523b407e63e8 100644 --- a/include/linux/mmzone.h +++ b/include/linux/mmzone.h @@ -38,19 +38,19 @@ #define NR_PAGE_ORDERS (MAX_PAGE_ORDER + 1) /* Defines the order for the number of pages that have a migrate type. *= / -#ifndef CONFIG_PAGE_BLOCK_ORDER -#define PAGE_BLOCK_ORDER MAX_PAGE_ORDER +#ifndef CONFIG_PAGE_BLOCK_ORDER_CEIL +#define PAGE_BLOCK_ORDER_CEIL MAX_PAGE_ORDER #else -#define PAGE_BLOCK_ORDER CONFIG_PAGE_BLOCK_ORDER -#endif /* CONFIG_PAGE_BLOCK_ORDER */ +#define PAGE_BLOCK_ORDER_CEIL CONFIG_PAGE_BLOCK_ORDER_CEIL +#endif /* CONFIG_PAGE_BLOCK_ORDER_CEIL */ /* * The MAX_PAGE_ORDER, which defines the max order of pages to be alloca= ted - * by the buddy allocator, has to be larger or equal to the PAGE_BLOCK_O= RDER, + * by the buddy allocator, has to be larger or equal to the PAGE_BLOCK_O= RDER_CEIL, * which defines the order for the number of pages that can have a migra= te type */ -#if (PAGE_BLOCK_ORDER > MAX_PAGE_ORDER) -#error MAX_PAGE_ORDER must be >=3D PAGE_BLOCK_ORDER +#if (PAGE_BLOCK_ORDER_CEIL > MAX_PAGE_ORDER) +#error MAX_PAGE_ORDER must be >=3D PAGE_BLOCK_ORDER_CEIL #endif /* diff --git a/include/linux/pageblock-flags.h b/include/linux/pageblock-fl= ags.h index e73a4292ef02..e7a86cd238c2 100644 --- a/include/linux/pageblock-flags.h +++ b/include/linux/pageblock-flags.h @@ -41,18 +41,18 @@ extern unsigned int pageblock_order; * Huge pages are a constant size, but don't exceed the maximum allocati= on * granularity. */ -#define pageblock_order MIN_T(unsigned int, HUGETLB_PAGE_ORDER, PAGE_BL= OCK_ORDER) +#define pageblock_order MIN_T(unsigned int, HUGETLB_PAGE_ORDER, PAGE_BL= OCK_ORDER_CEIL) #endif /* CONFIG_HUGETLB_PAGE_SIZE_VARIABLE */ #elif defined(CONFIG_TRANSPARENT_HUGEPAGE) -#define pageblock_order MIN_T(unsigned int, HPAGE_PMD_ORDER, PAGE_BLOCK= _ORDER) +#define pageblock_order MIN_T(unsigned int, HPAGE_PMD_ORDER, PAGE_BLOCK= _ORDER_CEIL) #else /* CONFIG_TRANSPARENT_HUGEPAGE */ -/* If huge pages are not used, group by PAGE_BLOCK_ORDER */ -#define pageblock_order PAGE_BLOCK_ORDER +/* If huge pages are not used, group by PAGE_BLOCK_ORDER_CEIL */ +#define pageblock_order PAGE_BLOCK_ORDER_CEIL #endif /* CONFIG_HUGETLB_PAGE */ diff --git a/mm/Kconfig b/mm/Kconfig index eccb2e46ffcb..3b27e644bd1f 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -1017,8 +1017,8 @@ config ARCH_FORCE_MAX_ORDER # the default page block order is MAX_PAGE_ORDER (10) as per # include/linux/mmzone.h. # -config PAGE_BLOCK_ORDER - int "Page Block Order" +config PAGE_BLOCK_ORDER_CEIL + int "Page Block Order Upper Limit" 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 @@ -1026,12 +1026,13 @@ config PAGE_BLOCK_ORDER help The page block order refers to the power of two number of pages that are physically contiguous and can have a migrate type associated to - them. The maximum size of the page block order is limited by - ARCH_FORCE_MAX_ORDER. + them. The maximum size of the page block order is at least limited by= + ARCH_FORCE_MAX_ORDER/MAX_PAGE_ORDER. - This config allows overriding the default page block order when the - page block order is required to be smaller than ARCH_FORCE_MAX_ORDER - or MAX_PAGE_ORDER. + This config adds a new upper limit of default page block + order when the page block order is required to be smaller than + ARCH_FORCE_MAX_ORDER/MAX_PAGE_ORDER or other limits + (see include/linux/pageblock-flags.h for details). Reducing pageblock order can negatively impact THP generation success rate. If your workloads uses THP heavily, please use this -- = 2.47.2 Best Regards, Yan, Zi