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 57840C83F1B for ; Wed, 16 Jul 2025 16:23:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EA9936B009B; Wed, 16 Jul 2025 12:23:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E811C6B009C; Wed, 16 Jul 2025 12:23:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D486E6B009E; Wed, 16 Jul 2025 12:23:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id BF6AA6B009B for ; Wed, 16 Jul 2025 12:23:13 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 3EFDF1DA446 for ; Wed, 16 Jul 2025 16:23:13 +0000 (UTC) X-FDA: 83670647466.13.65B416F Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.14]) by imf21.hostedemail.com (Postfix) with ESMTP id E4A8E1C000E for ; Wed, 16 Jul 2025 16:23:08 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=I0YS5rcS; spf=pass (imf21.hostedemail.com: domain of matthew.brost@intel.com designates 192.198.163.14 as permitted sender) smtp.mailfrom=matthew.brost@intel.com; arc=reject ("signature check failed: fail, {[1] = sig:microsoft.com:reject}"); dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752682990; 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=G5BbA2MZGX6Ufw1W05a8r4vL3Y50P3p1SWMHf+tk4ic=; b=WBy2pdcBSdXfJ/bybj8j2XeysfZ+2R1zYhzYkZCBxviiFlB6arIyC8ccF5vSj6n6uOhDYZ 9dIx4sHnGynGCwmJEKGkFcQ7cKw6VTiURBnX7iXirLwncaRO2K2qpGi0BTsOyxAbam/3QE MweOYltJLvO9b7sp1tAQdsKbKLWivV0= ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1752682990; a=rsa-sha256; cv=fail; b=xtzcq730e5eT4xeuN09Lj6faRmvsvvni1oz3nBEGOGCTmuW95aVOu0CoU3RhKOREYFc7WY Bi6nDxQGTviVvDJykq/GmhbH40g0qpQq+q4yPBkPcX4jyQ3PyNK5fnAblFX3iBr29GsUez WCiN6HaaKGix1FHOP1lQ38m0yYKpxZI= ARC-Authentication-Results: i=2; imf21.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=I0YS5rcS; spf=pass (imf21.hostedemail.com: domain of matthew.brost@intel.com designates 192.198.163.14 as permitted sender) smtp.mailfrom=matthew.brost@intel.com; arc=reject ("signature check failed: fail, {[1] = sig:microsoft.com:reject}"); dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1752682989; x=1784218989; h=date:from:to:cc:subject:message-id:references: content-transfer-encoding:in-reply-to:mime-version; bh=ejvB5HsY7lcX5a65TP5G2DddmFFgPut5Og2NE5V+Vug=; b=I0YS5rcS0O3x8ENOBCMWmlPMm1sWiKxhUos2t63vFV1nOgUNdLL4RJep d69syVeLn3NDBSKcdeVxc76jUeNTggv/edgZ0QJcu5gzv00RUks7zmnHo A+D7s4tGardmq5ExKrsuHNwgGVWvJk4wbALqRlY+3LZRn2pX1LV3apom4 ESoHme/uSBqAeX6CwlrkjFokjtHxhfx2W5MEIJFuCpuvZReKTFBVlwC0X ZGkr6ngAZnTzT3v20ywcec7LDk6x42kkUVNhYXf5LcSB2o2IYwUTEjI3L 6MXGWPaXHJZf6efixI4S/BGhDoAvq0WqlRgI7c/M64mYvHPxPA5LiFqVJ A==; X-CSE-ConnectionGUID: fkPZYAIMQAupUUV3Bd6efw== X-CSE-MsgGUID: EqrDhB7mTme7xz6lcLX4UA== X-IronPort-AV: E=McAfee;i="6800,10657,11493"; a="55030109" X-IronPort-AV: E=Sophos;i="6.16,316,1744095600"; d="scan'208";a="55030109" Received: from orviesa010.jf.intel.com ([10.64.159.150]) by fmvoesa108.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Jul 2025 09:23:07 -0700 X-CSE-ConnectionGUID: JpiScASCR3Kg+PnYgEIb7A== X-CSE-MsgGUID: 697Fh/f2RGG2W7DteD6NTg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,316,1744095600"; d="scan'208";a="156954871" Received: from orsmsx903.amr.corp.intel.com ([10.22.229.25]) by orviesa010.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Jul 2025 09:23:06 -0700 Received: from ORSMSX901.amr.corp.intel.com (10.22.229.23) by ORSMSX903.amr.corp.intel.com (10.22.229.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1748.26; Wed, 16 Jul 2025 09:23:05 -0700 Received: from ORSEDG901.ED.cps.intel.com (10.7.248.11) by ORSMSX901.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1748.26 via Frontend Transport; Wed, 16 Jul 2025 09:23:05 -0700 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (40.107.93.85) by edgegateway.intel.com (134.134.137.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1748.26; Wed, 16 Jul 2025 09:23:04 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=sj9g91nl5mP2b9sgguPsFHAbYOf3RumI8S4YUxqD79+JlpnJLDJ5FsOYXYZJnA3pbt9KANW3WhnnDFNui6sSkyd91JBEU1V57FC+jycFkFKK0j/r6dyr0fTTNR/d5+0BO/aFoQXMlmvy9sXPqyNO1lKLLT8+dNe4AZSG5bLfJ3eFFJN8QWpH7KH2emdv9iIPI3dzfUl+GvG8dCQzgMKQh/YgoRtAJRwKRMnKjXXxbB0yJq2a0O+dZgTLvf8IrLNY0szvGnkZFALXLrJ2KcKBy6Qc4z9CQZIftxAgQRhQuh2FC0+BDWF4D8242LSDhLxP7fXRdth35NQ44FX7/JCjsg== 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=G5BbA2MZGX6Ufw1W05a8r4vL3Y50P3p1SWMHf+tk4ic=; b=apeYA5dmXxKWPP2XXKZcR2QbrIfugQ06P0VX9HbXazRLGkDu6AlUfTCkFK88gtyjn/zUBB3RzV6uxYK8QgETmCk6dANnIUWN/JbrqXW7ToB2Jaezyf9o2hDTvho1MbE+wZXL7Ps1HWevLaVgHly6Ob7hl8kU+5Gfu/SO5aM6KADYe82/WjW68qS6jOEZGS1yVpbUQrhk978tFo9xFXcmGRXROXP592xYCYoPz3K2X8G1YnmxOX0Qj4KVnAZ0Kba5YcSjKMuZfTpq6MuhMDjoM80N0gnRJ9uAKm6Fnd2aeSPYOeshQSIb4DXC+PvpeFc7ycl1flSvDFObmVtWmJiixg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from BL3PR11MB6508.namprd11.prod.outlook.com (2603:10b6:208:38f::5) by SA1PR11MB6686.namprd11.prod.outlook.com (2603:10b6:806:259::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8901.35; Wed, 16 Jul 2025 16:23:01 +0000 Received: from BL3PR11MB6508.namprd11.prod.outlook.com ([fe80::1a0f:84e3:d6cd:e51]) by BL3PR11MB6508.namprd11.prod.outlook.com ([fe80::1a0f:84e3:d6cd:e51%7]) with mapi id 15.20.8880.021; Wed, 16 Jul 2025 16:23:01 +0000 Date: Wed, 16 Jul 2025 09:24:45 -0700 From: Matthew Brost To: Zi Yan CC: Balbir Singh , , , , Karol Herbst , Lyude Paul , Danilo Krummrich , David Airlie , Simona Vetter , =?iso-8859-1?B?Suly9G1l?= Glisse , Shuah Khan , David Hildenbrand , "Barry Song" , Baolin Wang , "Ryan Roberts" , Matthew Wilcox , "Peter Xu" , Kefeng Wang , Jane Chu , Alistair Popple , Donet Tom Subject: Re: [v1 resend 08/12] mm/thp: add split during migration support Message-ID: References: <20250703233511.2028395-1-balbirs@nvidia.com> <20250703233511.2028395-9-balbirs@nvidia.com> <1a451d37-56c3-4d60-8e06-3abae72e6bbd@nvidia.com> <007E2728-5BFC-40F9-8B8F-25504863D217@nvidia.com> <906590D4-04E2-40CB-A853-25FE6212700C@nvidia.com> <1DD0079E-0AF6-49F5-9CB3-E440F36D2D9B@nvidia.com> Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1DD0079E-0AF6-49F5-9CB3-E440F36D2D9B@nvidia.com> X-ClientProxiedBy: BYAPR07CA0101.namprd07.prod.outlook.com (2603:10b6:a03:12b::42) To BL3PR11MB6508.namprd11.prod.outlook.com (2603:10b6:208:38f::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL3PR11MB6508:EE_|SA1PR11MB6686:EE_ X-MS-Office365-Filtering-Correlation-Id: b9f353e7-ed5e-4a53-5b7c-08ddc48508db X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7416014; X-Microsoft-Antispam-Message-Info: =?utf-8?B?Ky9PTzc0RGs2VWlXallsKzl4eS9PVGxjUlZoc3VtMDFWbVRneEQybzlUYXpT?= =?utf-8?B?Zko1VC9yakdPTWFLUlpZQllWTDdValRrcjNpRmRpb0NsRVVlMEcvL0NGWHB2?= =?utf-8?B?b3VhODdIZTd1NG5vaHh6Y0VUQzk1a0ZlS3lYZE5aRkpYTXpiNnh2ZVFSdnJ4?= =?utf-8?B?OEtXNkxNZHVjWU92cXNDV1JRYUJsMU80TWhQeFI1WlJ3ZjZjM1VMRURwVEE2?= =?utf-8?B?R1JVazg4UEdRcXEwVDFDa0NkWHpsaG1SMWtCM01HLzlIWDdKaVk4dXJoS1N0?= =?utf-8?B?MDhYb3pPeW5WeWt6czE4UytHczZoRDE3OGRUdUx1Ynk5MkZ1Z3VEMitOYTVG?= =?utf-8?B?aUNHdzk2a0JZYitwVUQzd3V3VFpPdkxONEtWMFJaSUhhOFB0TllZK0hydmRo?= =?utf-8?B?S2VsSUYyREpDSjhDUTlxTGpNTGVUYUViYnVNYjRxZVJUaGpzU0hEelVyalM0?= =?utf-8?B?RjAvOFdSck1DRDVXcWV0em1iek9LL3B0NnFYZ2NzY3NBVUVoR1Q3NTVpbzhM?= =?utf-8?B?MjhIWDhLYzE1RWljTEhGV1M2OElsL09wUWJUb0ZINFc5djlaVGZVKzQ3N2hE?= =?utf-8?B?c1BGUXlmMVJIQjF1U3dFS0Nvb3c5aXJDZy80dnNRYk1wUjE5YUMzK3lkL2Vt?= =?utf-8?B?N1NEM3hKdFNNMlNuQStDL29ySFpTQktOcllGZ3JsWFlhQXBnTFZuajIrSTg3?= =?utf-8?B?aHd4QXcxTmZzd3RzSU4xN05IS0ZlaVF3d2NNcjV0b3UvOWRpaWs2TTY0M2lK?= =?utf-8?B?aDhhYlpVcXd6Wkd2ZWkxc1dlWXdLVDlQSStIaVF4eVNSY2xpU1NYQnZwVS9N?= =?utf-8?B?VXBsYksxdzFNTmVsVjd6dk05blZFSDAwWkJJcnBRSlhrME13aTRwK0trcVFw?= =?utf-8?B?T2R3aE5XSHp4cXF0VjZqWi9GT2dDNS9GVWN3amhNek8vcEhXeTloNDQyNzNS?= =?utf-8?B?RkhnTEV4UHVYWlpzRGY4UUYyc2hDUjRNSjk5ajhLMElkNkR5dFdPTzBFMWhr?= =?utf-8?B?R3ZRUkNDWnZENVRTdkxpNjc0NithVTZTN29xV2NFd050eE1Cck56Y05lcWUz?= =?utf-8?B?UU44bFpGZElnVzRPRksyQW45eE9uQm8yUGdqQTlJYnk0TVA2RUFCUWloN3Aw?= =?utf-8?B?c1dzU29ibTVMMTF6OFd1WS9wdyswWTAzeWlJRDkwNG8ydnI4bk9PTnVlYnUw?= =?utf-8?B?YXdMWFhwelpmOHJSSGVFWEptL3IwT3FpWXdZRityZ2pRUDZ0UFRVTndjU1F6?= =?utf-8?B?RllnQVF4Yk1YamhQbVN4N1VvMHB2c2hpUWptL0lFc20rYld3WnlQWHlSbFkr?= =?utf-8?B?Z1JKakFDSFBvZjVyL29tTFlDR2I1VXRORXYySzZvMmFRSTBoazZIdFVpY1do?= =?utf-8?B?NVJnU01iMmV1MjY3VFQyZGgvUnhSaFVFOU5lN0lwOTdsMUxYTGduWEx6T2lK?= =?utf-8?B?YzlKR2Z4bjRERjdSc3U5V1N0VW8xSHRtZ2F4WDRZL1lBR2lnRW9WbzVsc0Ny?= =?utf-8?B?SVhGajdmSi9vRDFDZTJUVmd3eTgyQkpyV3p6NHpFMXdub2RGdEl2MWJlZnJl?= =?utf-8?B?NTdPQUFHcE1vdGZoMksvYzRRb25aWXRIVkJ0UFdxbFhPbTJiTUpRMnhBb29z?= =?utf-8?B?Umx4SGpodk5YK2QwTlB0NFI5MmY4WjFRUWE3VHJYZTJqT1Ava3AvQzlUN0li?= =?utf-8?B?cVhKUU5YSy9RL2xGbDBJNU5scGZCSnZJbDFtMDJxSS9XUDR3WnhOazdyQnRR?= =?utf-8?B?eDR3TFVUcllQQTNjbUxUcUpUZmRzbTd4ZmZuOGNKNWRIYUhKWVdmTkVzai83?= =?utf-8?B?TXJuRlNtRXdJV2d2ZUdSUlR6aCt6d1o4cFlZOEVaYnhleHZidkFoa01zQkJq?= =?utf-8?B?cVlCbTNXd0JRaFpzOG5tTlM2UlBscndqOXR4QWdJdmdsWkFlTUpWVURVWExo?= =?utf-8?Q?jCIAppmLMR4=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL3PR11MB6508.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(7416014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?aThKcVF0blZhUjVWaFgrTXF0YTFkTEpGQjluUU9Pd3dxelNOY3FSRGhPak9s?= =?utf-8?B?QzlwSHR4WVBZYks3d1F2QUZvcFY1U2tRc3gzZm5uaFdMVWVqNVBWTG9YRnEx?= =?utf-8?B?NnhOVk8zZTk4Y29DdnFvMHFtUTRqV0FjSU11YkN3SlVMQWpZdTNmMFZ0SXBF?= =?utf-8?B?VS9XSGxqUytIQi93KzduQmw1SHlXUXJRRlVnZGRkNjdqRHFLanhaSC9vTVRo?= =?utf-8?B?bCtFY1RtOWloYzhTSGJROWhUL3Y4Ujdkbk1XZW95VkJqOFE1QUR4dlJZUnFl?= =?utf-8?B?N1RVTzZBTUxZMy9GYkZRanE4OEVGWlduZU1HaVlreFAxSTVaL1ovekhyZWlu?= =?utf-8?B?Vkp3VnlNOTNlaElHWFQ0UTNKdWplV3RvNlAzTlRWQnRtNVhyVFdWMmZmdDFC?= =?utf-8?B?cUxxa1VvK2w0SjV4MDFkL1ovcXNwZEZIVjNpNXJnbFdmenRhQTZiOFBuQW1t?= =?utf-8?B?N0kxV3Izd0kyN3FvaE1UOTFSWjh1SC93b3Nxem5td1dxbmN4LzVaR3NYajBR?= =?utf-8?B?R25yL0NoenNCcmNOa2RqcWNzSXkxVFp0RWtQMmcrOUhkQ1YrSTNWRVFQc3dy?= =?utf-8?B?UlNMWjExRnRkUE15MmUybmgrQU0zZUFqUFRsMk12N3NxaFAvTHhMNUpxM2lj?= =?utf-8?B?RUlteGtWRm5oN2ZJeS9wdUVNVHdwMERKeHBkbEhFWWFGNnVWaVRCYjNyMkRq?= =?utf-8?B?YmlLQkxIR3hVZHVZbzNlQ0pGZi81Y2VuTWUyV29CbDlTc1Z3RnVCbmNZYWlD?= =?utf-8?B?ekM4enorK2w4NTJDMEtjRjlhNlI4aGlGZ1ZSNjdlblFhcHlXU0owYXZiTERJ?= =?utf-8?B?ajVucjB2UE56N0ZQTXQzeTRMSU1BQk1IZHQwY0FydzY1OFQ3R2tlWDFWSVp2?= =?utf-8?B?WmtnclZ4UzI1WHg2UnF4S1JwT2RSa0gxZlhlMkdKa1h4THY1L1psdzNnWVJE?= =?utf-8?B?bWdsOVUzVk1LRmlMQlU2Y1pETkxHVTdxSGRQV2hSYnJxMU8wRS9mSVJuMHh3?= =?utf-8?B?R29DT2crdFZFc3lBdXVUNzZPV09hOHVQSWh2SUt1S2tXQ3M5cFVobHVEbjNO?= =?utf-8?B?WnIxTU9kajk2QXZpV3NENHZyd3FqMVh4VmFTdzNIVnJyQy9WNVJXNm5jazNJ?= =?utf-8?B?RjZBSHordHNSa1VkVmx4QVVacXppd3psS1hGMkNhNGQ2MFdXSDhUc000ck5R?= =?utf-8?B?M0VxWEJjZTZtclV5VlpRczZZV0JnRUpUcXA4M3JXbVZTeWhkaDZuWnBxV2V3?= =?utf-8?B?aWhDdmxNV0Fialk4aUFSM2tyZHRmUTZEbnp5dUppb09kUExNUHZFY1RIU05P?= =?utf-8?B?WkVLQ0dvM2E3aDdiVnRPTS9nZG9TcjRlTkNIaE9GQkp3NE5hOFNjTlZkSXBp?= =?utf-8?B?YVg5NU41QnFuVm81ZjZ4THJiK0J6djVnSzV0NEtUTHU0NDJiNTk1VEllUWcx?= =?utf-8?B?UEZFMTdvcG5iQnJJVThrWEptOXNEbGI3VUdkWU41ZThXU2taYWtaaTV6YVky?= =?utf-8?B?MjVuOW81RU9EUTllNyszMlFUb1N1UTVEUXZML1hqNEF5aHFVNnhheWQybG1P?= =?utf-8?B?UUNUU3poYmxoMkFTOWdYenlpM1V5TE9MMmNGVk1CNS9FampRbFNYbUdJRTk1?= =?utf-8?B?NjhpOE9mVmg5UzFnUVBLYjVhbmVUVjZ0bFJkSnB4TGpST1NjcGZKYUpVTGZv?= =?utf-8?B?WS80V0d6MHcrQnI4SW1Id0ZUZUVZTzcrSjUvQUhwWjRFck9VRkdVWjlaT1p6?= =?utf-8?B?KzFRVmtPdHNobTNzQnczd01VSzVSQXo1U2dzcUhCVDZpNENpNHhpVjIveFFK?= =?utf-8?B?UnIrNzBtejVJL0VJOFlRS3pqS2xsTWhvMGluM2FyeERlYzZwc0xrZVUyS1lU?= =?utf-8?B?UCs5YWhhZVY2TTQ2c2x1dDA2SFg3SER2WEF0RXZsUUU1b2UvK2lySlFraE5F?= =?utf-8?B?dU1TZEhoeGU1VDhYdUIxQVRIckZ5QzlaemRzQ2JReXRjVngwMTl1ZzIxMzZl?= =?utf-8?B?MUdiTFRTWkFGRi85YWF0NytncTl3dFJhZlpJWVhpd1Qra291bEJOMWkxVUs4?= =?utf-8?B?S0VVQkFsVE91bEVIa0EzQUp0djBQQTR1WStmdktMVVlKQlovVjl0TFlzQXQy?= =?utf-8?B?UTNJQmhudkJtaTZ1dDhESWV5SXlvRVl5R05WK3A0NEZqOEZjQXJ4YlFPcmFt?= =?utf-8?B?SXc9PQ==?= X-MS-Exchange-CrossTenant-Network-Message-Id: b9f353e7-ed5e-4a53-5b7c-08ddc48508db X-MS-Exchange-CrossTenant-AuthSource: BL3PR11MB6508.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jul 2025 16:23:01.7579 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: hQ+aPpp5R5BnZfu84ZWvW5IazoUIN2xZr3Tb1b7xaPfZu6seFR4/EmWu3aDCFJqBTR/NR9Zye8pe0rnGcqMYLw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR11MB6686 X-OriginatorOrg: intel.com X-Rspamd-Queue-Id: E4A8E1C000E X-Rspam-User: X-Rspamd-Server: rspam09 X-Stat-Signature: k396pyt4xne58bgi8phc8dsgiqdzksks X-HE-Tag: 1752682988-262942 X-HE-Meta: U2FsdGVkX19EGkmo5JlYihQhF7SHXBlauIO4BsiiHYv1sbjfjYA2t3pbKg7EjF+qmChzwb8xAIjF+QSLYOLbClJTqP23YNUk3umm3VvgKCndF1rpm0hiQYoxe3TpmcByihsYifOEkAphzLfLCPQ+1UTg5CQ2cg89qsJHRWqRvPzNbDpK+zKF/DDlED+6vTf/B65XvSU/GmL7b/f3z93gTduFWZYcxCP89LNJri/lVG9Ofwj903rB2Nl9DTaj6PNP4Z2o/O/AD4i4ZIrP08qG3wzcNM3c7Kfdxw3FSxPFcqr5R736tS631LT3M6ESrdo6Je/aXfI659Ih7k2O/vy4hqJgDOh/zYhnE0UPVKpQbBSTDKfU3DNc7ya8bcCrQ0F6LkF/IQXSiiuaTZiUIwSKC1sPLnwAZSYnLp/UUMW9Qvc7tnZOzRHq2l6Gox6kl/zkVKC6jUI9zRXajMtzmOw4A/0SwN/3yydMHEaUBxDALAb7PW+OlKyl85K2zFG2hS59WgTlsCjmWVw73I/l02T2x27WdtjM8bSBEfi052GTQo25ryq8QByiMxEs0drLlqY7f0LVUuwbrSzrub99X1ThnD6Sr3oL9kzeLsHaVJgXJUTiVCe9e/OmMWXlzoRSDDqJh3nnjh/7fqTaNsZ2KjhRkruhKPqAHuK9zkPBgqqR1WQmCDd5tF61CFAdEpNTM5Df+rLMMOzdl44OxmwCB0Tw1qIMl25wOlgc8KKksrxPihmQO7nBYXDE8Ggsp5rfZvYlbROlFl3tFakDGxLKvCIkLK3dJuYrgy1/A3STZkhHQOizcIj3WO4AiWXfVmLBYix+7yrBoRTfNnK9Q0OmEOnRk+LvW9TYtyCVj/iRO2cuYgxjAmbOV1WQ6awirBPJa3bkrrkoku1404rJx4cShCeknrkndsidoCwGQkmJelxsMsQOWedbaCSg1Y83FMrQ8+hNBN3m+JZLFth1NL1Rebd 11X4Rmf9 SZVax1wfDZuW5HdFLwYXFoePGDYzjPvnxqv5iXN6RfQCO18lG1s2onjnr6sOL+OiPjnao6Hs/2DyMxdcz/XqZjAi8QeoZ3b4X6NkFmkXREfCa7zcBy6anj+3nehZELmINKRie8LPZupHOBPxm89jyQQDTBlGD4dF3aQt1Rs9ggzZtfkYtrDuNzdyPW/Rob9AgyAOez7of8/BO8gOGsCyxwwM6uAg8hJcxOSQmASbIYkQKPFvBiykMLOHUdgyeuqhMtyeSeiEMRc6H7hcvt3+lJztijuj1Rdp3CcqB441XxdDw6OFVbWYDfwvUEQ3Wl9JFmSRw5EYY73jtdyCdbK4XYdSwKHvUifx2uX9732AlAS47OqRkEqNpY47+sd34RfKD6ODWONX9m467t3ImJ/vy6UTfDYB6nXCg7ke00/riYHzOrU/mIyd+61YYa8idqqfkT7RxdwFjRS8aOcILuYr07wVrEG6NoizCzwOGWB+WXyOHxayizCfoS4tyZ0jI9Zhdh+bBc1oeahIMxRyCUTxZl0NMhHoJQqNqJMzvyfjQsPmj+s6NWjHhs9V0Yt52b5RNVD9zMTsQlWS+gOC4Y3eQCgV/0ZLC1LJaq7QS 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 Wed, Jul 16, 2025 at 07:19:10AM -0400, Zi Yan wrote: > On 16 Jul 2025, at 1:34, Matthew Brost wrote: > > > On Sun, Jul 06, 2025 at 11:47:10AM +1000, Balbir Singh wrote: > >> On 7/6/25 11:34, Zi Yan wrote: > >>> On 5 Jul 2025, at 21:15, Balbir Singh wrote: > >>> > >>>> On 7/5/25 11:55, Zi Yan wrote: > >>>>> On 4 Jul 2025, at 20:58, Balbir Singh wrote: > >>>>> > >>>>>> On 7/4/25 21:24, Zi Yan wrote: > >>>>>>> > >>>>>>> s/pages/folio > >>>>>>> > >>>>>> > >>>>>> Thanks, will make the changes > >>>>>> > >>>>>>> Why name it isolated if the folio is unmapped? Isolated folios often mean > >>>>>>> they are removed from LRU lists. isolated here causes confusion. > >>>>>>> > >>>>>> > >>>>>> Ack, will change the name > >>>>>> > >>>>>> > >>>>>>>> * > >>>>>>>> * It calls __split_unmapped_folio() to perform uniform and non-uniform split. > >>>>>>>> * It is in charge of checking whether the split is supported or not and > >>>>>>>> @@ -3800,7 +3799,7 @@ bool uniform_split_supported(struct folio *folio, unsigned int new_order, > >>>>>>>> */ > >>>>>>>> static int __folio_split(struct folio *folio, unsigned int new_order, > >>>>>>>> struct page *split_at, struct page *lock_at, > >>>>>>>> - struct list_head *list, bool uniform_split) > >>>>>>>> + struct list_head *list, bool uniform_split, bool isolated) > >>>>>>>> { > >>>>>>>> struct deferred_split *ds_queue = get_deferred_split_queue(folio); > >>>>>>>> XA_STATE(xas, &folio->mapping->i_pages, folio->index); > >>>>>>>> @@ -3846,14 +3845,16 @@ static int __folio_split(struct folio *folio, unsigned int new_order, > >>>>>>>> * is taken to serialise against parallel split or collapse > >>>>>>>> * operations. > >>>>>>>> */ > >>>>>>>> - anon_vma = folio_get_anon_vma(folio); > >>>>>>>> - if (!anon_vma) { > >>>>>>>> - ret = -EBUSY; > >>>>>>>> - goto out; > >>>>>>>> + if (!isolated) { > >>>>>>>> + anon_vma = folio_get_anon_vma(folio); > >>>>>>>> + if (!anon_vma) { > >>>>>>>> + ret = -EBUSY; > >>>>>>>> + goto out; > >>>>>>>> + } > >>>>>>>> + anon_vma_lock_write(anon_vma); > >>>>>>>> } > >>>>>>>> end = -1; > >>>>>>>> mapping = NULL; > >>>>>>>> - anon_vma_lock_write(anon_vma); > >>>>>>>> } else { > >>>>>>>> unsigned int min_order; > >>>>>>>> gfp_t gfp; > >>>>>>>> @@ -3920,7 +3921,8 @@ static int __folio_split(struct folio *folio, unsigned int new_order, > >>>>>>>> goto out_unlock; > >>>>>>>> } > >>>>>>>> > >>>>>>>> - unmap_folio(folio); > >>>>>>>> + if (!isolated) > >>>>>>>> + unmap_folio(folio); > >>>>>>>> > >>>>>>>> /* block interrupt reentry in xa_lock and spinlock */ > >>>>>>>> local_irq_disable(); > >>>>>>>> @@ -3973,14 +3975,15 @@ static int __folio_split(struct folio *folio, unsigned int new_order, > >>>>>>>> > >>>>>>>> ret = __split_unmapped_folio(folio, new_order, > >>>>>>>> split_at, lock_at, list, end, &xas, mapping, > >>>>>>>> - uniform_split); > >>>>>>>> + uniform_split, isolated); > >>>>>>>> } else { > >>>>>>>> spin_unlock(&ds_queue->split_queue_lock); > >>>>>>>> fail: > >>>>>>>> if (mapping) > >>>>>>>> xas_unlock(&xas); > >>>>>>>> local_irq_enable(); > >>>>>>>> - remap_page(folio, folio_nr_pages(folio), 0); > >>>>>>>> + if (!isolated) > >>>>>>>> + remap_page(folio, folio_nr_pages(folio), 0); > >>>>>>>> ret = -EAGAIN; > >>>>>>>> } > >>>>>>> > >>>>>>> These "isolated" special handlings does not look good, I wonder if there > >>>>>>> is a way of letting split code handle device private folios more gracefully. > >>>>>>> It also causes confusions, since why does "isolated/unmapped" folios > >>>>>>> not need to unmap_page(), remap_page(), or unlock? > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> There are two reasons for going down the current code path > >>>>> > >>>>> After thinking more, I think adding isolated/unmapped is not the right > >>>>> way, since unmapped folio is a very generic concept. If you add it, > >>>>> one can easily misuse the folio split code by first unmapping a folio > >>>>> and trying to split it with unmapped = true. I do not think that is > >>>>> supported and your patch does not prevent that from happening in the future. > >>>>> > >>>> > >>>> I don't understand the misuse case you mention, I assume you mean someone can > >>>> get the usage wrong? The responsibility is on the caller to do the right thing > >>>> if calling the API with unmapped > >>> > >>> Before your patch, there is no use case of splitting unmapped folios. > >>> Your patch only adds support for device private page split, not any unmapped > >>> folio split. So using a generic isolated/unmapped parameter is not OK. > >>> > >> > >> There is a use for splitting unmapped folios (see below) > >> > >>>> > >>>>> You should teach different parts of folio split code path to handle > >>>>> device private folios properly. Details are below. > >>>>> > >>>>>> > >>>>>> 1. if the isolated check is not present, folio_get_anon_vma will fail and cause > >>>>>> the split routine to return with -EBUSY > >>>>> > >>>>> You do something below instead. > >>>>> > >>>>> if (!anon_vma && !folio_is_device_private(folio)) { > >>>>> ret = -EBUSY; > >>>>> goto out; > >>>>> } else if (anon_vma) { > >>>>> anon_vma_lock_write(anon_vma); > >>>>> } > >>>>> > >>>> > >>>> folio_get_anon() cannot be called for unmapped folios. In our case the page has > >>>> already been unmapped. Is there a reason why you mix anon_vma_lock_write with > >>>> the check for device private folios? > >>> > >>> Oh, I did not notice that anon_vma = folio_get_anon_vma(folio) is also > >>> in if (!isolated) branch. In that case, just do > >>> > >>> if (folio_is_device_private(folio) { > >>> ... > >>> } else if (is_anon) { > >>> ... > >>> } else { > >>> ... > >>> } > >>> > >>>> > >>>>> People can know device private folio split needs a special handling. > >>>>> > >>>>> BTW, why a device private folio can also be anonymous? Does it mean > >>>>> if a page cache folio is migrated to device private, kernel also > >>>>> sees it as both device private and file-backed? > >>>>> > >>>> > >>>> FYI: device private folios only work with anonymous private pages, hence > >>>> the name device private. > >>> > >>> OK. > >>> > >>>> > >>>>> > >>>>>> 2. Going through unmap_page(), remap_page() causes a full page table walk, which > >>>>>> the migrate_device API has already just done as a part of the migration. The > >>>>>> entries under consideration are already migration entries in this case. > >>>>>> This is wasteful and in some case unexpected. > >>>>> > >>>>> unmap_folio() already adds TTU_SPLIT_HUGE_PMD to try to split > >>>>> PMD mapping, which you did in migrate_vma_split_pages(). You probably > >>>>> can teach either try_to_migrate() or try_to_unmap() to just split > >>>>> device private PMD mapping. Or if that is not preferred, > >>>>> you can simply call split_huge_pmd_address() when unmap_folio() > >>>>> sees a device private folio. > >>>>> > >>>>> For remap_page(), you can simply return for device private folios > >>>>> like it is currently doing for non anonymous folios. > >>>>> > >>>> > >>>> Doing a full rmap walk does not make sense with unmap_folio() and > >>>> remap_folio(), because > >>>> > >>>> 1. We need to do a page table walk/rmap walk again > >>>> 2. We'll need special handling of migration <-> migration entries > >>>> in the rmap handling (set/remove migration ptes) > >>>> 3. In this context, the code is already in the middle of migration, > >>>> so trying to do that again does not make sense. > >>> > >>> Why doing split in the middle of migration? Existing split code > >>> assumes to-be-split folios are mapped. > >>> > >>> What prevents doing split before migration? > >>> > >> > >> The code does do a split prior to migration if THP selection fails > >> > >> Please see https://lore.kernel.org/lkml/20250703233511.2028395-5-balbirs@nvidia.com/ > >> and the fallback part which calls split_folio() > >> > >> But the case under consideration is special since the device needs to allocate > >> corresponding pfn's as well. The changelog mentions it: > >> > >> "The common case that arises is that after setup, during migrate > >> the destination might not be able to allocate MIGRATE_PFN_COMPOUND > >> pages." > >> > >> I can expand on it, because migrate_vma() is a multi-phase operation > >> > >> 1. migrate_vma_setup() > >> 2. migrate_vma_pages() > >> 3. migrate_vma_finalize() > >> > >> It can so happen that when we get the destination pfn's allocated the destination > >> might not be able to allocate a large page, so we do the split in migrate_vma_pages(). > >> > >> The pages have been unmapped and collected in migrate_vma_setup() > >> > >> The next patch in the series 9/12 (https://lore.kernel.org/lkml/20250703233511.2028395-10-balbirs@nvidia.com/) > >> tests the split and emulates a failure on the device side to allocate large pages > >> and tests it in 10/12 (https://lore.kernel.org/lkml/20250703233511.2028395-11-balbirs@nvidia.com/) > >> > > > > Another use case I’ve seen is when a previously allocated high-order > > folio, now in the free memory pool, is reallocated as a lower-order > > page. For example, a 2MB fault allocates a folio, the memory is later > > That is different. If the high-order folio is free, it should be split > using split_page() from mm/page_alloc.c. > Ah, ok. Let me see if that works - it would easier. > > freed, and then a 4KB fault reuses a page from that previously allocated > > folio. This will be actually quite common in Xe / GPU SVM. In such > > cases, the folio in an unmapped state needs to be split. I’d suggest a > > This folio is unused, so ->flags, ->mapping, and etc. are not set, > __split_unmapped_folio() is not for it, unless you mean free folio > differently. > This is right, those fields should be clear. Thanks for the tip. Matt > > migrate_device_* helper built on top of the core MM __split_folio > > function add here. > > > > -- > Best Regards, > Yan, Zi