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 F254BC83F1B for ; Wed, 16 Jul 2025 21:53:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 382F06B009E; Wed, 16 Jul 2025 17:53:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 30C546B00A1; Wed, 16 Jul 2025 17:53:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 186166B00A2; Wed, 16 Jul 2025 17:53:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 009ED6B009E for ; Wed, 16 Jul 2025 17:53:54 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id B6CB38052C for ; Wed, 16 Jul 2025 21:53:54 +0000 (UTC) X-FDA: 83671480788.11.AD91738 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2073.outbound.protection.outlook.com [40.107.220.73]) by imf27.hostedemail.com (Postfix) with ESMTP id CB3E04000E for ; Wed, 16 Jul 2025 21:53:51 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=Nvidia.com header.s=selector2 header.b=lvyEo23o; spf=pass (imf27.hostedemail.com: domain of balbirs@nvidia.com designates 40.107.220.73 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=1752702832; 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=yh7Yxvp6GdGci41yXZQ9WTB9YwsWNEyXv5UGjXgIAeg=; b=gbRufih6bStSkZGdiDG2uiRknOb2Z19gPZzot+9qCd1C1uMryx5MU1wC5hncu81z70ktP0 S00HALmdrHvE/NiE8uBvnehJ7azMrytTNwkcBG7jorK/7Cd4uu4Eoccxd+CFIwLz+bFNcZ TGKdO7mjFqL7y8Xgxa8ozxb2ij/h0yo= ARC-Authentication-Results: i=2; imf27.hostedemail.com; dkim=pass header.d=Nvidia.com header.s=selector2 header.b=lvyEo23o; spf=pass (imf27.hostedemail.com: domain of balbirs@nvidia.com designates 40.107.220.73 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=1752702832; a=rsa-sha256; cv=pass; b=NuDk4fkqeXMeudogJhAimzu+8ZdFAVMfnuOCaZYCSEFCY8LzwrCeZ9g2firTZ1sPav79K3 yfgbU8UY/q2ZFxAJToYddP64IuA/ENjw666nnTAncy9vdUQkbSUl+apwh+yEzeFZitinQK /bVUma+pWdx296/1wAZ6G1gx17YGrlE= ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=k7l0yiiPU/TNt+RKLelROr57N/8pzhtREpVmSIUmlogYjD443TLLh2EGlj9xzS6RU7tcv+Nqx91mpUrcJJdwbZDq5zDsZzE263DBNvtfWqbgDcF5pwIP0xpDM1QGZ3C8eawpnDSCE5PNSSRZhDXx52G0OlX98d0AplVt8UlKeYnWAuVhlhjSIOuFJkPUI3qmch48LRlpH3BOVj0Nyvbv8Bu9Q6UMHGbKURt18WRsfIjlT+3yzfFSkS1LaCvtRKFrO7bK21R1ZBt+P5STAG8lFo9vIcUCCimzyguJ2lBU77bi5EsOZfjYrycjg5bS1fAz2QDS38VaS+UTxwalDuc1qQ== 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=yh7Yxvp6GdGci41yXZQ9WTB9YwsWNEyXv5UGjXgIAeg=; b=UsLDVX6utomUl2cQo+8wz72kJ6CCP9NMMgBdpF04lbbJf1Ls2kXboV/7gugVBIK5TBmgt9jwInmIKVcEs1vAQsRLtHBbPZYkHslC0P6UN3PSMbej9qfv4WqoQihnUn3osaAXvo3a3bJEWWnUzPLIkfUcW79M8K/MgISxyVcqwMB/g2lxNwDeo3SgaIxb5Bh1g2GxZGQspxwEbbHckl9feRPGcYvlsn2J1bw8gDDf/ENUL2oAcIu4ZUMJ9Sf/UU1xVyRMsIFsJNBZubS3kqLW5fbQ1fLvIuUIhUOUH9nCvMzy9gwDQkSJ2ATUHINb1HudQNXA7m7MgyewLL4sMiLSJQ== 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=yh7Yxvp6GdGci41yXZQ9WTB9YwsWNEyXv5UGjXgIAeg=; b=lvyEo23oEOZXcbpRiHEj1nQkUEZA8ZfZDDxs5mZrGZWQbSbvANBgM3GYZXGLnOdZaH/j7bDMTN7EzFcUwjcey1hfMJgDryfFL6lyzVIxUlm1PpMH4vTqlLs32uzDmB2+YLRfoMYJTFIbmz2RED7wMEicgOkAUjko/OBe35NJrjffdrTKLVyoyf+ILbJwfO4P9HwwYG64mnHlVNAl54bRTm0fAjNafke79rqQJglwGryANm8aerdjhbG3z+jx8uKpmRwypt1J7J5/F6QaLgivWSz6L7upoWC9lyYbW0/PKAReeD0nRO8VkByCbp9VJ9GnatCWQzQ6/zLZqlzTDrHvgw== Received: from PH8PR12MB7277.namprd12.prod.outlook.com (2603:10b6:510:223::13) by PH7PR12MB6810.namprd12.prod.outlook.com (2603:10b6:510:1b4::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8922.39; Wed, 16 Jul 2025 21:53:47 +0000 Received: from PH8PR12MB7277.namprd12.prod.outlook.com ([fe80::3a4:70ea:ff05:1251]) by PH8PR12MB7277.namprd12.prod.outlook.com ([fe80::3a4:70ea:ff05:1251%5]) with mapi id 15.20.8901.033; Wed, 16 Jul 2025 21:53:47 +0000 Message-ID: Date: Thu, 17 Jul 2025 07:53:40 +1000 User-Agent: Mozilla Thunderbird Subject: Re: [v1 resend 08/12] mm/thp: add split during migration support To: Matthew Brost , 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> <1DD0079E-0AF6-49F5-9CB3-E440F36D2D9B@nvidia.com> Content-Language: en-US From: Balbir Singh In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: BYAPR11CA0062.namprd11.prod.outlook.com (2603:10b6:a03:80::39) To PH8PR12MB7277.namprd12.prod.outlook.com (2603:10b6:510:223::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH8PR12MB7277:EE_|PH7PR12MB6810:EE_ X-MS-Office365-Filtering-Correlation-Id: 47e61a56-0eaa-4e60-bee5-08ddc4b33ded X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|7416014|376014; X-Microsoft-Antispam-Message-Info: =?utf-8?B?dCs5ZWZSTHorZ2tRRHBrV2lIL3FvZlY0MmlHY21BNGowSHFvbGdBNDh1N21U?= =?utf-8?B?OVRvbGpBYTJZVHFDMjdrT3UyWkd3WXFITTRXNUhZTkd0ZHpkY0g2Zy8vVTE0?= =?utf-8?B?UkMxRHhOWTRFcENjdE53ekVDTlNsL3FkVU5CdGFaQnVYQXlNS05ZbVBjaDRy?= =?utf-8?B?bEprZysvTXdQL3BRUitWK1k5cTVXMXhyYXRHWmJ3WGQ5UUM1NGpYVm96WGxW?= =?utf-8?B?U2FhN01oSklxckkycXVZRnJHd1VSOEMrS1JUL3VSTUZDeFcwNFpzQ05tajNu?= =?utf-8?B?QTZ6OW92YloyTmNiNi91SmtrWUdML0JheWZVNHp3ZGVOSmg1YXo0M1BUTlY2?= =?utf-8?B?cml6eWVpZTJOME9BWS9MWDd4VC9mNzRYV1kxMmFjL2NjM2ZZTldZTDdDb0E5?= =?utf-8?B?N2g5NkhVV0tmU0V3UmVXVnJaMUdaNEp6Qkc1ZXZGaUVNU2hnU0I4ZlpZOGNJ?= =?utf-8?B?RzRnTlB6TmZoMFhPcjQ5RnNRR1BXQXBIZVRQK0dOUFppMXk2cFZaMXhIRVJz?= =?utf-8?B?ZXRIM0txSEd6RGl2bWJnc2VJeW9kVTNRdEtiM05jNkFMNUkzNHNiUzFRWDZh?= =?utf-8?B?VGdWdWtmd3VEdVZiaWJ4V3NMVE5lREJzbG5aVlZHSTk3UTAvRUlqRk9YMmU0?= =?utf-8?B?QU9YUWtzdjU5UVZLd2hmRUZDeXlhTXBaZWswd0RYZWNmMjVITHlEY0lPZ3Z4?= =?utf-8?B?YncxMEUyTE1yQ1dNcGFIMUZFWHBSWmtrZU1rcmVucEU4RU9WWGVSai82MDVB?= =?utf-8?B?QzNhamZOckdhbThBSjhUVjgzSjM4Q0Y5Rk5vMXpjbldHY1lnSnljL2IwUFBJ?= =?utf-8?B?MlZrcVorVzQ5Uk50QW45TjBkdm1OdU9kQWdlalJ5dnVjOVJSa3dlR3JFaEJM?= =?utf-8?B?Q1pUYWRjdE5MNEhSajQ2R3Zya1VRWmpIMDdxZDdyNTlBdXBJUWN4ZkhMTHJK?= =?utf-8?B?TjZTa0t6SFA3S3RUWCtuQ3kydTlQU25nODJmaFhpS1VwQzQ4R2lTV0VjL0l1?= =?utf-8?B?UDJpM0NFS0tsRERMSEplQ0QrT0Fjb2RlU2FoTXNZUnMzelpjTWZnYWtzQVVP?= =?utf-8?B?ZmxIaG1oMTk2VkM5bUk2UWhCc3Y2UGRxYTk3dTZzTEJuZis2cU5nY3F2WU5G?= =?utf-8?B?elVKRHh5S1UvYWdUdUM4YWVQTm9FSVpIS0xzcERRbnJ6dzY4MjBVbnFrb0Vv?= =?utf-8?B?SVdRWjFXQldRM2UrTzMvUS9ndnlkL1BHeVArdWJ5Qkt0elkzVzhaUlhzR1hv?= =?utf-8?B?MSsrWGFzUTl2WE41TXI3U1ZTRElkSHhVOWpuV0JTVHltbVZ0dm1qM0RveE4w?= =?utf-8?B?SFJkem40cG95ekpFMjlxYVU3K1VOdFNoeEYvakl0NHgwNUVkZUVTdlZKbW11?= =?utf-8?B?cjhZYjd1OVVoeWFvUG1mWmhSelVkODhQbXE5Zi8wTzdqYnZRTEJRQWUwTjhw?= =?utf-8?B?TEh4SDNHcmZEYUVFdU5ETlhvaXdmRFl2ME5WQkkzbmdncTMyRHZFYVhFVyta?= =?utf-8?B?dFpzM0MyN2ZoNGJzUFlGOWEwcjVENDA2eWpKN0MvOU1KY2ZaQ0tXN3MxUWRk?= =?utf-8?B?WHZuakRJbFhEZDR3K1RlVkZHVkNHb2VyMHZOZFJNbFdiRWs4bGtUc1RDUVNr?= =?utf-8?B?MnV5REZpQjVmMzVTQkpDRExpUnpOR1JUMjdNaWtLMFRoMmdId1l2TkhXM3lq?= =?utf-8?B?eEYrU2xoSmtTTytLczNnbEhsWXlQRnZyMWJGZWZleEdZTEhSa1RrM1B3TzE0?= =?utf-8?B?Q1RLT3hmZFhOSUdoU3VOM3E1NGRqUXVjb0lxb3lsWGMxNFIwbTR1TERPdVVT?= =?utf-8?B?YlpGdWhIeXJSRkkvZVQyUVIzQWh5U1lFb05HNWNjeW5RWnpvSC9RNStoL1JQ?= =?utf-8?B?bE96dnJ6SWdnZnVicnF5UXBCTVhGWDRKNllxTEtwZUlTV01SUTNLeGFaYlB0?= =?utf-8?Q?Huuz7wsE11k=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)(366016)(1800799024)(7416014)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UzJMcjJ3dk5kTzBSZXNxMWxWK2MxUVU2aFJFNzFhZ2l2R04zUGhaSy9sSGhR?= =?utf-8?B?cCtzVGNNMElDTmE2TkZMYWNDS1ZIL1ZwZFgrUTFyL285SW4zL3VyZWFlVUZi?= =?utf-8?B?VmZ1L0EwcTF2Zm5OUENkTUZpdHFPY1lkdEZYYXhpbVVMSEUwdnFWK2U4ZnhL?= =?utf-8?B?QnYyRGlmQlV6amJoWC9pOHd3R3Y2dldsS29KNFNPYWI3UEFmdDFTSjVlRGZZ?= =?utf-8?B?YUoxMlFOWVVPR1dFRmJjUUFzSkJOV0JoVXg2akpuOGRNa0FsSC9CaWVnQmhP?= =?utf-8?B?NkgrMlRDQWRkOHVzL05xMHVyY3Z2cjdDL0tacmRiNDUrTU90a3dKTTFuOGZF?= =?utf-8?B?MXE0V053SmcxdkxkQkhYS25MK040TzZjNUR6bXYrKzUxUkZTSGU3eVVqRTIz?= =?utf-8?B?TFg1WlRuOGl3M2t1NU1HeXZPaDlqWVliMlhWTjhSemZjY2VZSEZ1b3hkcFpu?= =?utf-8?B?bkZhSGNOVlF1eis0RFNZTEd0WjEwREtLU2pKcFdmeFRhcUc2NDJ5MEh3N2lY?= =?utf-8?B?d2V2VGYvNUFqVitVblhzQTBrQytZc3NqMkNXbXNHQVlRejN5ZEZCa2NEMmgx?= =?utf-8?B?Y2FjbDNEY3ZnZnJxQVZHei9KMVg4R0tPNG90TnUxam1RRWwyRFF5Q25pNTNh?= =?utf-8?B?UWdWTlhMK0RrZmJVcE5HZmFFcTdSUUJTdkVqTytoZ1g1ZWNiYVBpWFQrclE2?= =?utf-8?B?cWRJUk5DbHZaNVVnVlVZUUM2V0hvUjBQSFhESVEzZzJQRERTN01Pck9YKzg2?= =?utf-8?B?WGp1RkU0UThOVEppZXlHZGk3MmhIVTh2SEhUdVBJcUtYRk96V0hBSFNLS2xw?= =?utf-8?B?dmluTWlRdkVHdFUrdGlOU3NVRW1sbHc2UXN4TVhXQzR2MkpvV1loUWJyc1Zk?= =?utf-8?B?aWZMejJFZ0dXT0c3RXBJRWZyRXg3Q0ZxTXBrRms1Y3dDSUNmbDJ6dmhCc3Z6?= =?utf-8?B?MGRHVlFUMDJ1L1l2eTgvUHRLeHBiU0xaa2FzcnNyZ0lsU1dEY25pOW9xUUVB?= =?utf-8?B?UmN0Z0dpUitXczJxc3dPcHhsaFZpRnJMTVJQKy9GRVBZUGJnc1NCSXBCZGx0?= =?utf-8?B?cDZaVUxJKzVoZks0Vm95MVJ3YzQ4MWtYSlFrcjJmZ3Z1YTJRT2MzeDE0NWxW?= =?utf-8?B?U0YzMHhrd1Q0QVVMajZzZnkrMWhRK1NiUjRObDJiTUdJVURlYlZRNHdMTHJY?= =?utf-8?B?S1dWSXV0K1hyTkNkNE9UVHFzRnVKVjBXMlZpOWYxRTd6YmZ2eGVjNHpnOUtF?= =?utf-8?B?a0tzVlhWL3U2ZWhpdjdWRC9vWjBzazJZVWZWQ0xSUXIrQnE3dHcwZ29Bckl4?= =?utf-8?B?QmdPeWQwTHRWaHR0andiNE1BdDZRR1JkUk9tZ1hIYW1QeFVhUWc1RGsrbm1v?= =?utf-8?B?eUlucjRrTisxbXgrSjJNbjZndFRrT0xhdkwyZHRkQmoreVJpV2JBSmVsdDRh?= =?utf-8?B?Vk1kL25ndDF6bVpQNXIxVTJQNFlUOUVYbkU3TXRyT3lERmxUVVV3Q3k3MHFP?= =?utf-8?B?NzV0UzFGc0Q5YW1GYStraTIva0o4WVl0ZVU5R1NLVzFlVi9Dc0JlN2QxMmor?= =?utf-8?B?b3ZVNTIrRUxEMkZ3ck55czNCK2JGL0dPMVg1R2QvbGFJRzN0TGtHYWtNT3ZF?= =?utf-8?B?bmt2bExnM0RGSXRxTEc3ZFRKWXJSYlJ3bFBmOWhwOStIVUVYc25qOWppSzFO?= =?utf-8?B?WTM0TjI2NDBxVnZNTEY1Tkl0Q0hmUmJLTndGb2tBTDVjN3ZXelpJbkNxY2tC?= =?utf-8?B?S3BwTVpaTWVkUSt1UWIvVDNScHRKVUZ0SUMvZFpwNVFpQTIyUEhvRDZqKzZa?= =?utf-8?B?UEZFWlVSWnAwUE5SQjBONVYxMVRKaDEvU0tvcHd0ZGlnTUg3YUVzSXNRL2tt?= =?utf-8?B?M3UwLzFkTW5sbUt6V0xjamY1WW94eGlQSzVhSEVoNWtmSm1GYndVWnNjdll3?= =?utf-8?B?c0hWd3A4SGc4d3BQNHo1WjJRVExxby9tdVRNMThNTFdIdC8zR21SUEFqZ29z?= =?utf-8?B?TXJTeFErSWdTTnVHcXpyM1hTd3pXU1RTU2tnVjF1UzAvK0ZoU2diYkExRXpE?= =?utf-8?B?K093Q2pTRFRHSjlsRU1IK1JUaTlYMTdiU0VmckhVN0V2enNPNENwc0N4N1lV?= =?utf-8?Q?MWCYXz/CGXB0zmlJH/ZN8DRXx?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 47e61a56-0eaa-4e60-bee5-08ddc4b33ded X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7277.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jul 2025 21:53:47.5694 (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: oz9PYbsYBBZGXoGhTDjGpA4v9yg1bZ5gQfj9YWuUMCJAHftvUGB2xS+FnITXCCTGg+1tJmOBAOMc8xn9Ih/gEQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6810 X-Stat-Signature: 19otgkqx8o37wdnbw1d9skr6fj4gtwnj X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: CB3E04000E X-Rspam-User: X-HE-Tag: 1752702831-379206 X-HE-Meta: U2FsdGVkX1/m0J/g4axqfBfbq1dhw/uqEiY4mAmXQ8XeBfBSX3vfXTKDv+nef/E9wq4lJtP9dnZd7nOiHWRTnfZMTr2V51x2RzyaI4pnRgnR1ZGOLfv6gdxwJeWQQmY5sorfTMHI1E5K9Kf3oJbULRWdmHRWS5mgXFck/+Q9GgGm64EpBW+4Nk1Che6GjgAMh0fOUNtbl9e6ggJtTOQMh5JVrDP6dnMKtGiAnLrj0dJP33MZtmydQEnPvLXqWzwIo344Ir6diytMwIHpxHwZJ9HotQF7PUnH1u6kKHh1aly1GT6hdw3vKlVNy/lQO1qyOluJljRsxhbwOnQ+azTHSFF+qMKMCjGFcCUYwyaLzuU47kUW7bxNeyox7cB1pSR2lPsnJxMu0tIKsEIMJ/IVwIVUKwJOPPXSoeGI2+si9E5M2UM8u9YmkC9M7F6091KmRWVAIR554vScomCXhbzQ7lKExQhNTWzMF7gzATiZ9n+27vVRXPn7dX0LRuLF9Gr/aLI7xWkIB4R3AMimC4JUS7iyFFtAK6wbQDuXkcko1F6g5yo69XvaFkadMZXBGdrEGnugOncPoYCCh4xPLgUwNH8FdxQhcELlQzOptklKpMpIXMhUb1QoQkuM7E4vJyD4qw+FoI1soZj4T8/KtLd6GyS53g3k6Ki8KVhIt/r14uBMu1A29O7aDY55GmUm7omvPWNgXoX1rYcV5IJe0JUr2aI7UJSY5kA3wn0tDsWrFKXdh+m5md+CWoaohzvUnslvczkummObJTLWixm0KrJ3/+uBltvtPRDnmKIQS8RyMi9q+zs23Znz9DizG4nwceiOT2Khlo7COb7qkOmaOBMXQ6l8UFxY1NYbxak27+xTg7EI+bS5xm/qbKTCbFNI96yeQRvxRr6NPMEHC/4/DdUo97R72I90/m+sz+IQGtp2mp3+8F6120xItEqTGi5SZfvCGKlMp6YPBzQ6l4Inq2g Ydd7xqK1 7oI3B1v+9GWchGO2bSH4IP0kcPBp2xIFS9ZoJe0ONni+1pvLC0KKKibe8yhBcBXNlGUcs7F73id6aC2uh+b6o+1ZBRWu3FGYhYpRVp5qlKViqmXmCLbShvM0m6/gJ1SEFdy4ImRtmsfDy8qWQs0cb86J6us86s3vqdA9vaAZQCvGtiaj21staILdd5hSW2N7ej8d+stCAm7iwC+RNcI9ibP17rd9OcZThbN0E1CmSTjYpz7+JLbT1/gHcm+LZM8HVb5VY8dPKNkYYXztjr06d9zeWBXpUuxbXzyRrz+erG5L50QcRwQAogGKGtraoTTnvMl2fcNhPqn+fxKRoASF739yi1YC1C2+o/xg5mOhkLaTO3NXyjt9VLOVa4QIg6hwsNlo2hCgrkpMnclSZhNqMq+wKeJs6FTJi4wsunzeEvvRZo3JSzXlP/sWJCI+y3bMvMnm27qzny0+Kh682jyBOIdBUWXx89FSed85rKhduy9i1UyhdHiyPipTDTCnmJWrQ2Lcu3Jcao9o7CoPcPTJVqApbPA== 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/17/25 02:24, Matthew Brost wrote: > 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. > I was hoping to reuse __split_folio_to_order() at some point in the future to split the backing pages in the driver, but it is not an immediate priority Balbir