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 6750CC8303C for ; Sun, 6 Jul 2025 01:47:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D97566B8075; Sat, 5 Jul 2025 21:47:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D41466B8074; Sat, 5 Jul 2025 21:47:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C08896B8075; Sat, 5 Jul 2025 21:47:25 -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 AA8ED6B8074 for ; Sat, 5 Jul 2025 21:47:25 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 4643FAE77D for ; Sun, 6 Jul 2025 01:47:25 +0000 (UTC) X-FDA: 83632152450.03.E36BBBF Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2062.outbound.protection.outlook.com [40.107.236.62]) by imf16.hostedemail.com (Postfix) with ESMTP id 58E9218000F for ; Sun, 6 Jul 2025 01:47:22 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=Nvidia.com header.s=selector2 header.b=mHK2Nd1j; spf=pass (imf16.hostedemail.com: domain of balbirs@nvidia.com designates 40.107.236.62 as permitted sender) smtp.mailfrom=balbirs@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=1751766442; 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=n8SV/SwU5a1k9b6wJzZZHw+5rPnmyghfuvMkdJ3Ty/0=; b=GuKKQvPj6afxG1dFmvyyMLNAvddJy8IR2HoVCrBTCOhsJfPnH4cgcuAATA/cSmT6jnfm+Q T5nkW9ddg+4apa1h587zTbYrmKyWjWVhHU041Uzv5WR1Xdm0UkwbcDzVka3HMvmvh62p+e rWS0ojCmRSb4t4rKCZVBExX1ncbgMM0= ARC-Authentication-Results: i=2; imf16.hostedemail.com; dkim=pass header.d=Nvidia.com header.s=selector2 header.b=mHK2Nd1j; spf=pass (imf16.hostedemail.com: domain of balbirs@nvidia.com designates 40.107.236.62 as permitted sender) smtp.mailfrom=balbirs@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=1751766442; a=rsa-sha256; cv=pass; b=g4YZZy92NyDmt5z/2AxZBZO5kOp2DB5iDOVDIXAXBnujIbPZ8r/fMRxAZcrLg1je5d3+PF JNcVcRdVxNp2DKYGzMrbn714xqp78CpClSF+8vcuxBpJqDbsN7FE38xoXbONEbIkVaYIjF Hs2Ex/fJ76Xsnos7H6YZ9AVI5/0fyLM= ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=SZwN19U8kIy8JKuqrHqjVp7ELllOcS2ZMyZQG+vmgxg4YxSPX/s54rUnjfTFDTd5Cxk6HADNtYaVpV9pSEHdZb3x/4k7MpKWLGQI+ZkcOZR8oZLBmit81kxG7yKjgD4lRCi+nN1zwYOKMroNoDn0yJ+DEWLfKixOnSBU8q2qDZt643jCGSDUw0RuSj2yJalayzdkGJHzaLJn1zCI94IF52JKm03HRTn5j+oLI2ngFGApsAj/dEBnGoYKZgG7bypayn08Rcn4Yr+VTfUrc+s0vC2n3pqMyX1nbzM3Fuz9XQTPWWWbKebL71PF8k881j0KC3VfZyNgQveGDlQUqrwvzg== 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=n8SV/SwU5a1k9b6wJzZZHw+5rPnmyghfuvMkdJ3Ty/0=; b=X717cy6FnH+g+d4qc+swDIaE9pIpO5HfBSZRIjcD//3ugjMi3w4rIxEVXAd2d9BPRpKwgWXsurbQyCQusrvQDQ1sgSbm4itgtsxCziGvGhNvZc21wRPpjj6r80Gg6Wp/23P7xL3qqi0jAHRmDrsb/ZzVlLOAAh3gd9GPYrXKGslVAb4ZdU9ouFdZDP+EhEWdPqbswraQfM6Ng10A7Nkb7JPNTDZQJOi4YefuwnHve/EhccQ+Q/ZxtqvKbNGvitmf07TU4AbW2BSzBJm3DhVswrYG5COWCjOIirFOUL04i/yolB86w8XXFJfJQlfZWT3NPlbZU616C9jwvqVDpUXMXA== 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=n8SV/SwU5a1k9b6wJzZZHw+5rPnmyghfuvMkdJ3Ty/0=; b=mHK2Nd1j6NO7ksD8MlcRl09niGYiR69//iiiZnx+W7sajB8aMdarrKys7XGsKUKmdx5cqBDdl/WslkwmefSGXSZGFF3cEa356CecN2Rf6I5T22a84GesfhvFVeg+10JeEBv2Kxph3GYQ1zTxrmGmIalph7L0pDcnPU9/cPb3Ey7IeW4NBJl55ep9YpjcRZG/p0uDjzS6uh3CWQb+tKcKVKaFJakjwyozWo4hMbf+YprzXa08mXcYqTh8zNVLBY95U5QSO2GONPC2t4YhuzfzgL//iUvUrX5oRekZq/IAOqc1GMs0MjISrCQYQBa0IeUZA93+8OTbtmubLUaEWp0I2Q== Received: from PH8PR12MB7277.namprd12.prod.outlook.com (2603:10b6:510:223::13) by PH0PR12MB8005.namprd12.prod.outlook.com (2603:10b6:510:26c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8901.20; Sun, 6 Jul 2025 01:47:16 +0000 Received: from PH8PR12MB7277.namprd12.prod.outlook.com ([fe80::3a4:70ea:ff05:1251]) by PH8PR12MB7277.namprd12.prod.outlook.com ([fe80::3a4:70ea:ff05:1251%4]) with mapi id 15.20.8901.021; Sun, 6 Jul 2025 01:47:16 +0000 Message-ID: Date: Sun, 6 Jul 2025 11:47:10 +1000 User-Agent: Mozilla Thunderbird Subject: Re: [v1 resend 08/12] mm/thp: add split during migration support To: Zi Yan Cc: linux-mm@kvack.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, Karol Herbst , Lyude Paul , Danilo Krummrich , David Airlie , Simona Vetter , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Shuah Khan , David Hildenbrand , Barry Song , Baolin Wang , Ryan Roberts , Matthew Wilcox , Peter Xu , Kefeng Wang , Jane Chu , Alistair Popple , Donet Tom 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> Content-Language: en-US From: Balbir Singh In-Reply-To: <906590D4-04E2-40CB-A853-25FE6212700C@nvidia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: BY1P220CA0013.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:59d::17) To PH8PR12MB7277.namprd12.prod.outlook.com (2603:10b6:510:223::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH8PR12MB7277:EE_|PH0PR12MB8005:EE_ X-MS-Office365-Filtering-Correlation-Id: c09b9499-90de-4ff3-3a6b-08ddbc2f094d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|7416014|376014; X-Microsoft-Antispam-Message-Info: =?utf-8?B?cjNLaE83aXJWMHcvL21IVjF2NEd1SzNYdjlyTHhUMUEza0ZZMlM1T0ZkK2Ru?= =?utf-8?B?Y09sdEJOZ0h2eUdhS0tUYXdZTUN0Uk4yaGkyRXNObDVKbkxnR0pKWUwzaFJ3?= =?utf-8?B?eDNoVnVuVktSeW15MVU3VDVyc3ora2ZMM29pSWJFbDd2ZXZHZUh1Ti9uTUFY?= =?utf-8?B?WURGdjNTSXBNWlowQytBQzNTWEszbE9USGpuT0YrWWIwdE1KRmZwbWx6S2Yw?= =?utf-8?B?cm9naTJSQ3FRV1d5MitqZ21lSXRjOWNlSXU4TmZPcVNnSElyc21lKzVmcDBG?= =?utf-8?B?WUNpUXp6aUJROU84aXJLQTNIYUkwa1p3TEhWdHEyR09YRk1hcGd5QVF0RzNM?= =?utf-8?B?a2I3clB4NXdyTEoxemh1Zmk4Y2xmc1hXbExhcEpVLzBqcUZEaTdHZS8rS0w5?= =?utf-8?B?NDc3RnlzMlV5UllrMnc4OEhCVCt0cDdhVHhoc1hhSXF1Z3FsQU5LcXZIL3lC?= =?utf-8?B?QmpaMmlyWnd3bCt3aHFhSmUxTEEvSGtuRTVTbzlIWkxFSFlMUGhQRGsrUE9T?= =?utf-8?B?ME1Fa2lsUkhYY09xZklRNitmRU9TYVlxTGgraDN0SktwOFk1MDJ5MnRPdFc5?= =?utf-8?B?MWJHdk9Idk10bElQWUxyWitNcFNTeGNLNjczMm5qbmZHSXp5R1FURE1objE0?= =?utf-8?B?UkxxajJKdDJGZDMxQ0dhT0FidmthYXpOLzdKaUViSTJSOGE1bGd0K0t2bmVK?= =?utf-8?B?ZkxxTHNiOGFxajlzcUpSUzhJcnQzWU5SaUFaR2FVNVJhK0Z1bEx6Vk9jbGwv?= =?utf-8?B?OWJDNWxENldXaGYvbkUwMG9BSTNzcFEwazR5UlBPbWk0YnBLK1FRa0tmSytG?= =?utf-8?B?ZUF4YUl6WEM1bkk5eExwclF4OWx2aEhkdDFFRDdOQzAyM1YraHdCS2tzUURC?= =?utf-8?B?WDBBWVhMdEpISloybVBFVlBjT0R6VjFkLzVxZE1oTDlrUVZsUFhhYU4vTmZX?= =?utf-8?B?bTY4UmhWMVp5QVFCVDQyRmNtMDNlZ24vRnFjTHNqVzdoYmExb0hlYS9BUUZk?= =?utf-8?B?N1hWOWVoOEd5SmxJSm5PK3Uxd3hjYjFWK1NlRWNnUzJ6KzF0QnA1T2pTb2hi?= =?utf-8?B?YTVUdHNuckduaTNUOVB0QXpUaHVtWjh2WlN5eUVrUGdVbjQ5TWNWbEIrTUU3?= =?utf-8?B?UU5vZjNSVHJIQkRHVXlBVzJnZUFzUWFDbkI5Z25Na3EvY254blU4M2p0cUMx?= =?utf-8?B?OE5LSk1DN21PaWRZelMvSTdVTUQyc1JDZU9Vc241VHpLMnp2TXF0aGp4ZDJF?= =?utf-8?B?TmhpVXhjaGMwTHBwSGQweWN5L0t3TWdPdTNldXVsNlFJcVphdlhxRklSYmpw?= =?utf-8?B?UWZSRzJBVWVCYnVJT2xqV1E2TEN5WHV2eUlONEZNdkxkbzdJSW1mTkVKMWVq?= =?utf-8?B?VWMxUktXU0pIcFY2Wi84eFI5R3BSK21HYVI4MXNIS1pubzdQeCtlY0lrSTQ1?= =?utf-8?B?blpKOHRQN2orODZVQlc5aFdwSjZqRnlpWENFRlFoZXlQeVlSUC9DS3pMT3JM?= =?utf-8?B?Y3BRNDB6VTFQdUtqc3RISS9SNk1lb2xYNWdoN2lyMCs1SlFjdjdRamdWdW1C?= =?utf-8?B?TjI4RVJkT1pnbktSZG9xcUY2N3A4WWZUa2dJNGFDNFdOd1JzeHp1OTlDWnQ4?= =?utf-8?B?VjZUei9kTTY0cDd5ZHcwQVNHVVRmcTduM2tXSW5zSGhPQUdtZEZURkxwQXZW?= =?utf-8?B?clQycmVEU0NyVzY1UjVWSU5BWll4ZlhvdzF6d2dIK2lSY2VLY3RvM2xQRFNv?= =?utf-8?B?anpJS3NCZHJtR3lmV1dTSmltQWdFbGw5L2FFZTZQMW51T2Z0RThnQjNQcVlX?= =?utf-8?B?UE8xdE1iVWdtbzNzZVNhZUk3SXNDWWd3eGZLK0RPWi9WTGZ4bkYzSXZmQ3p5?= =?utf-8?B?TGNsV2xqSi9DeU01RGxnTThZZUUySlhqQVVPSVEvVlVrSkhRenFNQ0t2Vzd4?= =?utf-8?Q?gK187/ivFoA=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH8PR12MB7277.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(7416014)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?T3ViMmI0TVFlMzQ0OFFnZmJ1S0xGZVhPV1F3ZnRwci9JUVVBL2FERGFLcVlZ?= =?utf-8?B?OEN3WW12TTRzUGl6aUlKWXZaYXU1THB0cFR0SlV2Z2lURVkwQ3VPOG1jbXdw?= =?utf-8?B?aTNyUXprczNxRE9LcktvTi9URDNwdWEza2VHTjQzaFc5ekFZZi85ZnZuNFJl?= =?utf-8?B?NEZjZG5UZjBsM0gvanU0YUM5SnpEbVZHVEJ4SmttOGhuM3pUWUwwQ0VpeEw5?= =?utf-8?B?NktPMko0cjRrK1JPZlQ1MU5rbnFveXVJQkNJM2lLektNTHF0bUh4VzJTZTZW?= =?utf-8?B?Zm5UZkE2MnNJZVhtdkF5VGlvSEQxaW9mbWpuNm9lK0Z4VUs4Zm5aU1VoMDIr?= =?utf-8?B?bllRVGVzcjIvc2tSWVJVaDBhUUF6M1hhOFI2ZUtkaUFEQWRqcnNlOVNLK0lv?= =?utf-8?B?YTZ4SnN5b0ZXUURlV0ppN1hrNC81cjBwYlBUQ0FYTEVuK2ozb2lsVFY3WXhW?= =?utf-8?B?enYwTDhGQU9TakNNQzI1aEg1Nnd6Qlp0NUUwZ3B1MlpPV0ExRG1MRnFkN2d6?= =?utf-8?B?SlFmTXJCd3dZYTBpN2pFUEE2MUs5YXhhRjV6TUJlTmJMYytKd2pSejhHdGpU?= =?utf-8?B?Z3k2NmFpU3Jlcmg5VGdMaXZDbTBvWWp2bzFyNXhOeTBiN09RZnBWMSsxcFZj?= =?utf-8?B?Rkd4NTBNVG9hbEc4RWIvczRmYlVwT2pLWS9wdmUxTVNnbDNsZ2N6UzBzb0Vv?= =?utf-8?B?ZXVaU1ltUU1JMmxGcHZIUE9vSXFSemIzMmtmTHk0c1FEYll1cTBzaXRDVTM1?= =?utf-8?B?ZmtIRWFQOEhiWkttNThaU3VDRUFZWmNHd25HOERNaDhBbHJxWHpSa21aVm1u?= =?utf-8?B?VWk1cFl1SjdPcG5JZ1hYYUdxbWlNendWV0RLamVTQjJzM2Q1ZS91RDRCTXN4?= =?utf-8?B?MjVoMDdpdlQ1dE1LSGdwdHRXSE9lTjFIK1RScTY1M0JYbHdYVmZ0RThSeGEx?= =?utf-8?B?eEZESGNudVFVV1VWQW1CUUp2bDM2UFRUQnpEbUtoZy8vMndZS29BdTFtdzM5?= =?utf-8?B?c0E5aSswRDlONmo5RC8vcmpxaFF1V3cwcTREcmVqd2hVdFFpZEl3Z0l3blJH?= =?utf-8?B?VkQxSkpZaE4wemxvdnV0Zms1MVZCUHNTV0JORjNqdkhTTVByRDJOVXREbVpD?= =?utf-8?B?OG1rRTVlSGM2SXlycVd4UFFVTzZEUXB4VmZNTTlRRGpGbFhoejV0TG00RmJ0?= =?utf-8?B?VERiMW5IWHRRK0dBWDRNZXRVMDhEUytCOUNqYVJ1ZXFQcytDdU5yNlFlWVFw?= =?utf-8?B?YnRteHFEWUY3M2U5WGY5V24zYkcyblZMcUs5U3lBZlpnK21RWWR3TjFoK0RR?= =?utf-8?B?VnVrdnNaVGZLRWFlQ3ZrVmg1SW9QUjN5RktBSmVpaTlsQ3NUSmNQRW1PalFC?= =?utf-8?B?TVlYV1NhZ1B3YlVPRnJMVmpvNnF1dHVoMUgyZ3dUaU5kMmJacTcvQ25kVks0?= =?utf-8?B?bG9EQnVBVDQyMDFWaGZVd2tqMEpQT1FkTk16U3FpNE4ya3dRUVVkc0dXSjdE?= =?utf-8?B?TE5TUU8zYzF5RmNoZWlrejNFRXdmVlJkamtubXZvL3YvQ3dJSnVXaW9sMkhC?= =?utf-8?B?aXc1K2ZwTGpNS3I5VllGYURJR3Zkd25RNVA3ZVB1d2NzeG4xeGpEalozS0kr?= =?utf-8?B?eWp6eTRLODRlQVlzWmxjSitJOFBYRkRyNWtPOHJJTjBFSXU5TTFpOFJXcDN2?= =?utf-8?B?Ym13QnRtYWpmeWhub2VEVGlxWVdLdFhKREEzZWhtVUI4UjlzUm52WUcwdStx?= =?utf-8?B?Q25jQU9zdlhqT0xGb0RMTWZaSkpuektTdnA1RVoza1lmUHZ5eG1KcUNmUjRR?= =?utf-8?B?YUFXSVlvZkRZVHRPRy9tY0Fod2YrR1lxVEQxMWp3RFNvTjE2cnp4V0FYTzE1?= =?utf-8?B?dkpLQUJDSE1sa3lWdC9FMy9PeHEwdDVkVzJ1TU8vRm5zODA5YXdpa3Y2RzBU?= =?utf-8?B?RW1TcS9FRjc0UzNVTmNwKzJ3dU1CREdubUhWQ1lzMEZnVS9Bc2lLZElDZGhS?= =?utf-8?B?emI5NjdwNnAzQnJvVGVobTlxRUdOQ0JNVmdraXZ5L3ltaXRMNEYvSDJubjQv?= =?utf-8?B?ZVQ2SDhmdkRDN0traXNKMktnbjlWaVUzSyt6MnQwRFNEUXhsNWk3VitRN1Bl?= =?utf-8?Q?f/bXtmCTrYDkrFMzjWDrOeda/?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: c09b9499-90de-4ff3-3a6b-08ddbc2f094d X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7277.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jul 2025 01:47:16.4408 (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: Emlj/0n92m6A/adCkCLgTYPSTtrpF+4owjZfmZg8+jc/hZkkkdBZBiETa3euSVYRv5Ueyg+eDpkyj8PjCgJWEA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB8005 X-Stat-Signature: hd7d3fqnifpr8jwwqthzfgai6ixmh1nw X-Rspamd-Queue-Id: 58E9218000F X-Rspam-User: X-Rspamd-Server: rspam07 X-HE-Tag: 1751766442-713332 X-HE-Meta: U2FsdGVkX1+mvWLHiiGWQEDOnS+pPS1Ai17AzdbTwZkjof6nVelK9yMw2GcDkyTPILLphZ66TH9GaWd8fWt+7XCq3TvVs4lRVl0WRnKzzXO4gWFHPteQ8J/NEcKW3qzRPbRvvmkB2A4SGrpoF9qYm97sivNox4fvP6a3G3xXKHMzc7frc36c8j2w4FWHyphEgYwW3EVf4WmE4XdL3R1az0CvjgKcuDNgopqlXBUeZjEse8xW/iP8etM3AHRhVbqtwoFtskGa22sK83fktRR9lqiH8X1bYZ/a4RAm71dzZfyo+ZJiKYpqi8weco01u3jiVmomKQiyYEDXD9nIhdg+E5YerJnYsHKkA/IwLn+5RxQqpuWXXDFQtzZkJ0ddgs1XTAO/aAjzu6NxHiEi0JLiEa6RL/aSBtGxJ/sALtWZOk45LbFSOH3kcrI3DUYl100qQNRanu9GZEuMkLLhIgLNO3vyMPfzN6rLmPl5lykdZ+8NFpEDao/NmO/ct7x03T0dP0yw2Z413N5lO2frpILj3iZGe6PtydUOuJBu/X9rQrYDumNYfpktKKhRld7HVXyq8KsXcWXiYSDPRpRyDmYNTH/SMlAYPI1ODDEcMb62n01heeEa/iOYK5vM+1oAGDVsqyzspWu8pmGzAiAl9R6jt5OTqSjo3zrWd+AajqjWE/xrZGsONF16V0aAFuLecxeNWLFDgU4O35G4boBe4qxLeF1A2L9bbOa4pgLqv5Sa+x3m6yMNS3MuGubDvxuc5TzrZuilWhYhbw7ooIyMbsMJ6DQ6h4hw17jVPWXFE37B9n2eHUP/lo8C923QmbeW/JIOrRZ5JChee8sT/pccvTpwIcB49AvoPJnIrJQ+d8Y71dIDaZhGt1ZKBCHGS2VJZ+n97Acy9VR3vmVBAIx0IZtSmo1R9a6hMlJvoR6RjNl+KpM13FXmWrsZZQv/KT59bt3gkS+gq4V1CFrPCdQHbfD jmakUBTn CffZBbTmIITtydxnzQMcToWs5AqJA39U4gg0VXy/etdqh/XvlGQPCikEKcQwngonFas6AJsVOTDgBjBqkV76RPLHLLFXwEfBJwf56v6P10hoQp/dfRK1cxEDadRP8DTjyJ3zPFGUBbhBbCBF3LucLAOf48EMMsn3c6KYgUxf4vuhXo6DAZ5pbaEv/zx8dZ6dgBbMXuDSQLMhjRB8byw2bIjXuMMXD3QiDgwjxu88NIS8v2zJ2j15IRURsRNt7CrI7NvEIca809ZBXONDVfoPA5Y5WqsZ4L1EWQwsfQu0FsoDng68HYsqYtQxqafoeuipzQKhEqgH0IYt/gmsEZ5PR7n8jQSIYEawEtbOV7bRGFTqBaPCELOBgKbr3H6G+XHr1YwiPLz2sJTH3xOVlcO/072dEDDHK4p37452iXR6h8lT4pUyfSWEY85q985APcxkXPR2jCf1Dbc/UWotBjfBEzqzGlQ== 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 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/) >> >> >>> >>> For lru_add_split_folio(), you can skip it if a device private >>> folio is seen. >>> >>> Last, for unlock part, why do you need to keep all after-split folios >>> locked? It should be possible to just keep the to-be-migrated folio >>> locked and unlock the rest for a later retry. But I could miss something >>> since I am not familiar with device private migration code. >>> >> >> Not sure I follow this comment > > Because the patch is doing split in the middle of migration and existing > split code never supports. My comment is based on the assumption that > the split is done when a folio is mapped. > Understood, hopefully I've explained the reason for the split in the middle of migration Thanks for the detailed review Balbir