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 44233C83F1A for ; Fri, 18 Jul 2025 00:40:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 84AC98D0002; Thu, 17 Jul 2025 20:40:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7F44F8D0001; Thu, 17 Jul 2025 20:40:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 695178D0002; Thu, 17 Jul 2025 20:40:55 -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 56D558D0001 for ; Thu, 17 Jul 2025 20:40:55 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 0139E12D7DE for ; Fri, 18 Jul 2025 00:40:54 +0000 (UTC) X-FDA: 83675530470.13.C3C831D Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.19]) by imf30.hostedemail.com (Postfix) with ESMTP id 2C5D280008 for ; Fri, 18 Jul 2025 00:40:50 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="Yucy+/t/"; spf=pass (imf30.hostedemail.com: domain of matthew.brost@intel.com designates 198.175.65.19 as permitted sender) smtp.mailfrom=matthew.brost@intel.com; dmarc=pass (policy=none) header.from=intel.com; arc=reject ("signature check failed: fail, {[1] = sig:microsoft.com:reject}") ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752799251; 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=SdSTqTYRjabZCmMM4SVuV1nTO5GHvYovhlQ/uowi7ss=; b=P7Tqwr1CjBCe2oqjOY/GLWoQ/GPFHmM5h+LjdcIfWD7+pOneVGdvSUhc/gSgiyU2/E60Y8 XFn7XcLRsiJAf0dGE7VVsVN1ALgQjGDFlKD1a8R9dLd7P1wZFutQghcp4vpK9c9d7kaf2H e0rIS1rkiXvztumoMVtoYIU+6N0jSyM= ARC-Authentication-Results: i=2; imf30.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="Yucy+/t/"; spf=pass (imf30.hostedemail.com: domain of matthew.brost@intel.com designates 198.175.65.19 as permitted sender) smtp.mailfrom=matthew.brost@intel.com; dmarc=pass (policy=none) header.from=intel.com; arc=reject ("signature check failed: fail, {[1] = sig:microsoft.com:reject}") ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1752799251; a=rsa-sha256; cv=fail; b=pGyqTifulwo204sjhAVyja5Bwev/rSC07fY5d8i5c2uegfbq9RBWchjcZp6V1Nyhywhb1p VjCuaYjRYsHNWza09NtZwOXg+anS7MqvJyMCSRmJEWhHnC404eOPFEjR6m2TZZImyDsD0n vZWXLcgxLPyn2pLeC6M1nak+af9KyzY= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1752799252; x=1784335252; h=date:from:to:cc:subject:message-id:references: content-transfer-encoding:in-reply-to:mime-version; bh=BmzjjbHnCaCtTgeGRLIA7csiF8gkS4vcGb24AzSrYQM=; b=Yucy+/t/Svmz1r1K3utzA7jvo2NOegW6b3iJ+h2TBeS8XyG0LUWJisIB s3dyStf88A0ccwoSMyQQyqS58GVVcN+2VIZmomxETubdV4FSWBKw8QJWU CrLrrrqIQeuANKhlZQ7wSGy0o90pOr+nGs/G0feJ+NrfBEezrLkfHVZh5 CbTK9+JhSGIQOBuevSbJriCP3PBazBKrpwHAnGKGwwNh9ZZQEoRhd4oPZ PqqAJ1ut92jvW1Jbln/yTe7GNNzaEd7RmDq/MjUf5svhTLAMe94MyJRXo 4hGnw5FikldU04pTifZV4g5x/w6C0KyUd349WtVBxAOl+CECogihyo4RB g==; X-CSE-ConnectionGUID: qLIWd+VGSCiXhjhGuE97Mg== X-CSE-MsgGUID: x5rRzfXiTIeed7RIGzg/wQ== X-IronPort-AV: E=McAfee;i="6800,10657,11495"; a="54947600" X-IronPort-AV: E=Sophos;i="6.16,320,1744095600"; d="scan'208";a="54947600" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by orvoesa111.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jul 2025 17:40:49 -0700 X-CSE-ConnectionGUID: lxnYHceNQ/e9F96MJjY2Qw== X-CSE-MsgGUID: Sb7RxWbkTgaWHfzIIuBK5A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,320,1744095600"; d="scan'208";a="181645164" Received: from orsmsx902.amr.corp.intel.com ([10.22.229.24]) by fmviesa002.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jul 2025 17:40:48 -0700 Received: from ORSMSX901.amr.corp.intel.com (10.22.229.23) by ORSMSX902.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1748.26; Thu, 17 Jul 2025 17:40:47 -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; Thu, 17 Jul 2025 17:40:47 -0700 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (40.107.236.52) 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; Thu, 17 Jul 2025 17:40:46 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=LZgKeW65SZqSqFhCZX4QztUZ8NqSvBTSV9k6GC6sZ2NucsjXlt9+tT6LC2JKJn7qW6K2g67vtNYmVz1Ex3vtHFa5eFtl9NBqCjTcWPcergccNKePsvCN26mROCCmQVy9GvCMGuSJFkK57JPcYhey+sDexKy0C3Sh0w/OS5iIXSx3tTwfUENzxXuhZ+wHYaa/IFKq+F7xcTVuwF4oPoleghn3gnsRMuiu07Q+DluR8kidsudbN+XHBDqciE1V4QCfxBc9IoZLwye28J4JwDnsDQwan0KEN8Q4I2ucUBStjmf7LzRgOcT7N6HwjKe73Q0OPKRZyfY/MJdkgtkLy5Vdsg== 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=SdSTqTYRjabZCmMM4SVuV1nTO5GHvYovhlQ/uowi7ss=; b=YM30NhDVhn2vz1NUt/4l/NGv4pm2vSHGCSmND3vjYnsDKRkI1gHN3ttyHRghqh31n53Lwb5wj5lzmGMj699slRwxj83rpi8UjGDPD56j0d6E+K5CkbhkZW9Ac1zvXbKSTwIHg5MFe4k81h9ykq5aR3CRX7VogcV/K4h8r0qNkPkej/5ydQOJhI8rnw858yBlBJ/jxGJnKrBngP1dfUbswnUrTGpfebqKwd5lKz2rJZ1Z1u7nOxQNPxnoN58Cm6UJEagtiwbYLkqqijRYDczJDhyO0A61YDjkVzlwyoe7GUai7rm3v/DI6Zh4mFKsnPIWcLUNFcj+OuDus4Mk95TeFg== 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 CH3PR11MB8773.namprd11.prod.outlook.com (2603:10b6:610:1cb::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8922.39; Fri, 18 Jul 2025 00:40:17 +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; Fri, 18 Jul 2025 00:40:17 +0000 Date: Thu, 17 Jul 2025 17:41:58 -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: <007E2728-5BFC-40F9-8B8F-25504863D217@nvidia.com> <906590D4-04E2-40CB-A853-25FE6212700C@nvidia.com> <1DD0079E-0AF6-49F5-9CB3-E440F36D2D9B@nvidia.com> <9E024BB0-7365-4A81-81E1-72CB44A07775@nvidia.com> Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9E024BB0-7365-4A81-81E1-72CB44A07775@nvidia.com> X-ClientProxiedBy: SJ0PR03CA0233.namprd03.prod.outlook.com (2603:10b6:a03:39f::28) To BL3PR11MB6508.namprd11.prod.outlook.com (2603:10b6:208:38f::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL3PR11MB6508:EE_|CH3PR11MB8773:EE_ X-MS-Office365-Filtering-Correlation-Id: 816ed2c4-81ed-45c1-d779-08ddc593aa64 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?bHVXYjAzZ2ovZ0ZIa0IycnN5ci80c3FpVEQ2d2ZFNlZ4RjBaZU1pSkNYSjNq?= =?utf-8?B?UW51R3N3eGRmR0E0Tmh6SlNiekZLcG5FWmhkK3EwcFZzYkZ1QnBxcWpVMFMv?= =?utf-8?B?SUpDam5UZGR4UHIrMkNMWWptYm9VMVRidFBabFRCMDFOR3d6TTJ5SkpBMktK?= =?utf-8?B?MEd5Zmsrajl0SXRRTWhPSjhJQVBhYXJzeTduR0hwNS9TZnNsck5pbDhNdlND?= =?utf-8?B?TWFIRXE4R0p4Ly9nMmluRm9WZkZPWWlHQk9HOU56T2dTclU3Y1kySDQyMEl1?= =?utf-8?B?N2hjSElaRkNMV0NST1kyQ29WY3kwNDVzNUNNRWYwSHhQY1crZnhlRFpGdVZv?= =?utf-8?B?ZlZnS1hxekdmZGdaSHlLSytBSmk3ZnhEc1JZT0JkbklXYUhndUJxNFk4Q3Iw?= =?utf-8?B?UkdUa2ZkTWJaektVNzlibWZJNUNwNVpHZ0ZhclFheDR5RGxjWkgzS2R6UVBs?= =?utf-8?B?QWFRQWhtYzlaa0lRLzJlck9yR25zMC8rOXQxUjdVOU8yUmRRaGg1RU1BSVJt?= =?utf-8?B?Smx4T1NUZXBjMUNlK2NNR1RaVWFwaE85SHJ0ZjVRcUhaNWt1dVFRamQ1aUZ4?= =?utf-8?B?NnhxRXlBWGk5RDJwSElMazRheTlvMkhmYXYvTnZRby9VUUFtYjdsTWtrMjVj?= =?utf-8?B?bmQzR0g1cUxLbnAzWW4yUUhobmhNYWMrV0NkYWFzcE9EaG10cm5pZnRyeGp1?= =?utf-8?B?WWJkWDQvRzh6Y1VRNDVub243MjNhOHlQWXNRdEgweW1UdGgrS2hFNXNMVS9B?= =?utf-8?B?SG82d1BjZDlZVXpNaExYMm1hcitqUHpoL2tGb3pFd2lIck56VUxoOFBxYnYy?= =?utf-8?B?V2t0WUI1NnJyU3RRR01YVWV5d05UOE9CYVAxZWlvdXdUM2wrMkRIektkVEZP?= =?utf-8?B?OSswdG1uM3o4OTNuemZEb01LZ2dBQlFDanBkMkRVMWxLNk5tRmZTWTRySWJJ?= =?utf-8?B?N1ZyZ2lNY3dJN053Y3AxSXk2bEE4RTBkQnpqMWhEL093dTg1N2hQQUlpZjdR?= =?utf-8?B?MTAybzRIdlhCcTRsTVZheFFPNTM3VTVlMVkyVmRKM0hwM0tkWjc4S3B5Qm5L?= =?utf-8?B?bUtFY3RrenZUNzVPLzZhSHJzV1BGR3FKT3ltY1B0aDhUcjlKaXRHUm9nK0NG?= =?utf-8?B?Z0p2aE1iYjdCdUwybzEzeVdCTm1tUGJ0SFY3YVkzWlJHZFRJeVpVZ3BqQ3dz?= =?utf-8?B?d3pFNHlWTXFZMHlvMmdHYWZYZ0VxZDdwR25xNDBxNHFsbjVucEpwMzNQVGNh?= =?utf-8?B?S2hBaGZyRWN0bVQ1UElSUHNFdHVMem1CNGZOdy9BSlVoL0syeXdJM3V5YmZD?= =?utf-8?B?Y2FLYjRTbGMxcGllL3NHY2VMK2MyazBlYWcrOGVLdDU2YmlzYWlEZTVwYWl6?= =?utf-8?B?Z3YxM05iUnlwMU9JWlhpVCsxNllWT3lzY0g4T3VBdC9Ud25MSTRaMzl2N1pR?= =?utf-8?B?NjhVd05JNjJHc3RLaWlwTTY0Q0VkZUp2Wkl1QlJGUDhJaFRCSG5sMyttQTNL?= =?utf-8?B?T3ZYNTU2QTFqMmRSamd1N1hwTG5SbGhTZ1VwUXFsN1BXUmRMc1ZmMFNORWZE?= =?utf-8?B?VVUwbkRnZVFnUnp4N3g1bERib1Y0aU9WZFhUa291WlZwYXRGSTZmYnBkMmkx?= =?utf-8?B?Unl3ZW1KY0xGS0JpRDdTUDNuSjJ6QzUvMlJYZTJtVnAyeGNZaHNjaDJVbENM?= =?utf-8?B?YnpkbCs5aTZLNTdMTXBGM2JnQlRJSFN3Y0JQVDVDc1U3TVcxSDQwaEJUbWJT?= =?utf-8?B?OXRPaU9MVWFxZjltUHo5b1lld1FLTFUyZDduaEhoY2xyZXZ2dzRYRTU0QmJ0?= =?utf-8?B?akpTS0lwSzQ2ZmtIOEt3SXE5TG1UY3YybkpqWmNRNCtMTDdkaS90WVpxM2FY?= =?utf-8?B?QURCTFdCWkRKbzJtRnl5MVJrcVFtL29FSHpPNFhRNVJHK0M1UXlVK2dYUkhm?= =?utf-8?Q?DOQsgvKZHzg=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?U0xKTUlPNjBJSjMyeVprbFFOUVF3a0NKcDN6eE9Scm1hT0gwbTJuNWc1SHhQ?= =?utf-8?B?c3dnVHdkNHRkVGpVcVd5bUVVbTEwWHpMc1l6SEdwakpkakNDT1c3b1o0dFg0?= =?utf-8?B?Wm9sdzdjc3VwdnVrcVJoTUtmNGUzUDNpRDZxWFU2WUlwclNjcDhROW9DVDhy?= =?utf-8?B?L2I5R2dwaXF2YkpNQzdmdzJNUDU4OGRvQllrWnNROW03T0FUTDY1cWpEY1Jt?= =?utf-8?B?VXhMSXNuaURra3VUVStmMVdOVTFkNnBwdDFNMDZjbDRKZ3ozQk5hTmcyRzFP?= =?utf-8?B?S3c3QWpyYkhkYko3VEVZVHB6dXlBYjRRTVI5RWN1b1FDcDJRbDRkM1BUWWlQ?= =?utf-8?B?dmtLL3VjR01aOUN5dHFkODl6enFzWkR0UnFTWWNiQXdZNFlmOE1FMUF1SmZ6?= =?utf-8?B?NmVnY1lMQWJ0eEZRa1JSb3BYaUdHcHFWVEJnb2RJb0poaVFyVktuY3E5VnRS?= =?utf-8?B?SFR2bVYwZXZLa0RyeGVRaXcwRnJZYjd2VlNpQjI4TmtVQjN1ZXd1Mm5QQ25R?= =?utf-8?B?czJGOWI0dFM5WGhBcE0zeEJERVd3d0EzaHQxSTgrNzhkR0l3UUxhdmYveE5U?= =?utf-8?B?T2JmcTdPczBUa3FhNkRyOUdRUTFJOTNhb2QvbW5DQnlkNGtkRG9OMXRhUXQ3?= =?utf-8?B?S1JKOVowUlJtZlBqNFZ5cDBhNDBtbDR2RWI3ZXZKcm0vUUROZHRMUkZuUTJy?= =?utf-8?B?QkZSY0tEOWYxWmlDMlFpdW5VUXQ3K3hEdENoNHBiUzAvRjhVVlJES3hHZDFm?= =?utf-8?B?R2FNalloZ3hrb3ZrOXdpaC8wQ0hDeGwxdFBTMnBKNEJOaTA0Y0VQTWVjME9j?= =?utf-8?B?a1RyKzMvbHRlWmIvNzNFem12ZVAzaFp3dWd5S2Q3ZGxESGdIU0M2Rk95S20r?= =?utf-8?B?Yy8zQkJGdVNLd0dSTTE2elA3VXlYZVoxNTNXYkJ1aDhKWE1GT3RVSzNjK2NU?= =?utf-8?B?cXBaYWtxaE5XYXMwUmUxUFk0bjZVSTNEdGhTYlZQQlhhYTB6d2xQOHB5VCta?= =?utf-8?B?cG9vYldFNUViRGc2ZE9xZ1dxdWxjdHBSRTVnOHFMTEZjQllYd04wd2J6ejE5?= =?utf-8?B?WkRYSWxUdFVhRlB0RnZHSjgzTmd4WVk5SWRWY1czcFN3Vm5UaTdvK3R1T2Fu?= =?utf-8?B?WHBCOE41S3RCL0U0SkhIVWxmSmdKQVBnelQvd3N2a09sQTA2em9SZVhZVXdo?= =?utf-8?B?Q21vNlcwZUsyQUhCRmJSM0hyVDlFQzYxYXNPclh1SExBVjdBdE9PZ2hWcWRF?= =?utf-8?B?YWxRT0dqMFlpMXdoMWp5ZkoxMTZZd1BQVzRHQW1QWHB1U3gvMmxNODFPejZh?= =?utf-8?B?UjhzOXhLNWlLeXFtTjIxOFYxOTFyS3hrZXROUzFmU2x5ckRLd2lEb2ZtWVov?= =?utf-8?B?SEp6SjNxTHZpN2JXQnpHaW02Wi8vVWNLYktIRVJMMFhUQkNnQWp2VzlSNjhP?= =?utf-8?B?N0lmN3huTmlYd0ZrTFFwbkdkUXN3N1gwV0pmZ1Zhb3RLYmhWbFNnWGk4aXNu?= =?utf-8?B?Y0FLaHBoYWVOZXpMK0tqNDBNSUtlNlhYN3BWNnJnY2N0SDRNSWR4NVNrRkZD?= =?utf-8?B?N1BBc1oxTWJidzZId0V6VzNkSmIwZ3ppSGhHcHd3QlFXY0ZUUGN0VWQzanEz?= =?utf-8?B?ckZBVkthUTlHTktGaGwwc2tSRFJZUnNsNDhLTWhYbkdzWjVSUXlWQXJnRG02?= =?utf-8?B?d0JTWnpvRjV2RDBva1JYM3FXeG9EU0RyKzZRYUtMM1NHUUVxWlBwMjFmclFU?= =?utf-8?B?TG10L3ErTy9Ec3F0akd6bHlMcHgzMFZ4Nit5aFBBZHlUSTQ5aFNZM2w3ZjBQ?= =?utf-8?B?S3RuaHVNNlVwT2d6L1BWMUs2YVhHQlY0bFkyZi9qcEZuNmlVTEtqOWtVNzFY?= =?utf-8?B?U083V0MxVndVd0FFTU05UG1NcnMvanFHZm5QMWVVRXdiSXRxUVZxUFZFRUpz?= =?utf-8?B?MGk4Rk9vNDl1RWlGblN3Y3R3dm1hZlV5bjJjdnA2bklvczhuMnJYNUd6TTdm?= =?utf-8?B?dElKRFE4OGxidi9OdWtoZFBUZW5oZmEzbXlMWWRJVExUMmlkY1dkMGJCeXov?= =?utf-8?B?SUlyZ0puZ0EzcE0waXpIWFErYTVGRkduZ2hzckY2NnNHSVc5K0tJRkRSMTlJ?= =?utf-8?B?ZVo0R1o4ZllKYUNZV3hFUHg4SnQ3NzhvSFladDB4V3ovSldBWTEwYnZLbFBL?= =?utf-8?B?U0E9PQ==?= X-MS-Exchange-CrossTenant-Network-Message-Id: 816ed2c4-81ed-45c1-d779-08ddc593aa64 X-MS-Exchange-CrossTenant-AuthSource: BL3PR11MB6508.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jul 2025 00:40:17.1067 (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: AbQ1dFSK6xN+CExDlcBIK9UQ4JVtqLzqkGZd4F1J6Eo/wf7mdFmCcFhRo1K/99sPmYrERpg6+Gc50ycbkbeIKA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR11MB8773 X-OriginatorOrg: intel.com X-Stat-Signature: 4xef9p6mhbeo4mmxcm9ha6toxco7rpcs X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 2C5D280008 X-Rspam-User: X-HE-Tag: 1752799250-565248 X-HE-Meta: U2FsdGVkX1+/9LaeUNSee+OO52rdPnOTInNQf8knUfPiuNrBvXAWJK6NCsRuNI/x5xKgBXXyrh9Zr3UgeQgWOXor9wkXem1puGP1hVzrv4Qpzld18Vh3+2tdrPPBc0t9ELM95GIvTWFEbRaL9Qsox2JY/bL/HUSpYTsdaN3x7YlogTyacPba+bxZt3QUioWu6ZM5uzlm49h+xr+Mf7WL6pC2HNlMwMtTVXeBSMu+cfVrLygsCvodoIxaETGonBCVrHoEx/UAA/Mpx+8iCWMmxBOnQeeYycOvmbA3diO6/lgNs80RSJP3lfiQ7UP6h+hx51RvkBM/KLhcQRHvGOcgl5I0lbTecpBjrADrvmdyY1HaNiXbFGFuN+6wqVtmUxqRClE+dkZ4DEKS1UyZLI7sn79dqXcJXKZ3HWgI/vtmz4dyYMl+r6ciMm9TEcspuRwpeh//IetCSMcShDe52ji3BbHHdinU7l7smhFHyckmtZ+yeycACfL8O6hwFYESV5BiUvrFCJwfprLA7fmoNYYnF5bagjM1ZNAtr2jrUDhJ8JPSB9WZgR3YJ2r6vJ0SqmVyWwRh9BL/CJSHKRaD8YFBVyekdGko4o7ndcYh3EoUYYwUzmfo2NM8StYDwqNFnacQuwXEb+Jd+OQnzG+0HNHdiANVVYYfMNQmajJ056PwSYac35d0bb7dfo/yRLsOysyRK9quOe4KK2uQH/UzFBV6G/y2hFK3Uk8ixbM73pzBTbpDwl3A6WGZ6YDEPRsXVJ0zbqr57DSUDeeQbIVUwtrAgcriFXxIW8wp2MWNGeuVN887VJBTj8KbAuxl8LfkvuAvkphaiVkiv+qeVIFan/K+2J08XPz/kP44mxhvVYsYVh2dFtWzLwF5XqR0oQK0RuRZwArxjTPKmiUbGgXx75ixAO4WQ6Z7toj2yOA28uWDFZmEyTy0K/edhp2vuU5JQWza4IJwycKAvD99VU5P+wi oVg== 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 Thu, Jul 17, 2025 at 07:04:48PM -0400, Zi Yan wrote: > On 17 Jul 2025, at 18:24, Matthew Brost wrote: > > > On Thu, Jul 17, 2025 at 07:53:40AM +1000, Balbir Singh wrote: > >> 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. > >>> > > > > This suggestion quickly blows up as PageCompound is true and page_count > > here is zero. > > OK, your folio has PageCompound set. Then you will need __split_unmapped_foio(). > > > > >>>>> 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 > >> > > > > I think we need something for the scenario I describe here. I was to > > make __split_huge_page_to_list_to_order with a couple of hacks but it > > almostly certainig not right as Zi pointed out. > > > > New to the MM stuff, but play around with this a bit and see if I can > > come up with something that will work here. > > Can you try to write a new split_page function with __split_unmapped_folio()? > Since based on your description, your folio is not mapped. > Yes, page->mapping is NULL in this case - that was part of the hacks to __split_huge_page_to_list_to_order (more specially __folio_split) I had to make in order to get something working for this case. I can try out something based on __split_unmapped_folio and report back. Matt > > Best Regards, > Yan, Zi