From nobody Thu Apr 2 22:13:14 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 625FA2F616A for ; Thu, 26 Mar 2026 07:30:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=192.198.163.18 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774510212; cv=fail; b=PQDBVxrNVqs6m3P9tw73ZAIHwGK3vkrF7jYsCjjeBvNQiFpswPgTnodyHiE/tCVGMsywY1jHinmnDwq2dR5dwBOutIrPu5NIGyLSUL/cHw0BKEHXNuw9lMwOcgPA5mhm00sV0oym9tTgRsBhufyTfQHOGv03RNdCkIofsUl4DVg= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774510212; c=relaxed/simple; bh=gu9ydUtNOVj4676RbmWtvNEjhFwdPOujDEBA4obFDQM=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=XFYEiqiX2PWqsMtihQaAEDexyegmOXthE6nmX06+8EL61MUOV+nxe7/E4GNWr0JgSAtZXoSzOCxHbV23GfnFjKQv5qNQOAOdBTKPxoXELLAEEZ6Ko1OnZGT+X0SJdW85SF6yqLz2Pkqz+H4m5dN5iC8Na1+gprdoEVxY3H1pJo4= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=k2AgTeIl; arc=fail smtp.client-ip=192.198.163.18 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="k2AgTeIl" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1774510208; x=1806046208; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=gu9ydUtNOVj4676RbmWtvNEjhFwdPOujDEBA4obFDQM=; b=k2AgTeIlf1MeU5l8i+R60JkYAbeYEYhDqY5OsoWOV5vJYQmJKCDa2uzQ AlBeSS4UnTYV02hOHJJQ9i1W3WBgNzUYh4fl9IaLyfTu2LoYzMl2rADin 1q3e9T7qt7wY8sl/M5BbTxoP8E9w3JJQeSbAGwpviteiTphbSdxRx5A3N eHFY42xJkGyfwbh/27UQROoqmfLP4bScjL9uAiDa4wv9KN9kw6l4CY/M2 tRoJpMecnem1IDq57blCBbiXs373VG+ljHwHoZ7rmXjqZ1AVvFd5O7I3G sdsWbFqks2+BETsXqnxMTWHf833LxihVFsI+svxK/RXOXv044jbzF1Dom g==; X-CSE-ConnectionGUID: OgHGuwXySRm6kaUNrBex0Q== X-CSE-MsgGUID: jhv7qM20QNigvNQdN3Usng== X-IronPort-AV: E=McAfee;i="6800,10657,11740"; a="74742527" X-IronPort-AV: E=Sophos;i="6.23,141,1770624000"; d="scan'208";a="74742527" Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by fmvoesa112.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Mar 2026 00:30:07 -0700 X-CSE-ConnectionGUID: aabN2omERAq0VkECufGjVQ== X-CSE-MsgGUID: qatV4PZGRXyidf6XGWCh1g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,141,1770624000"; d="scan'208";a="222022243" Received: from orsmsx901.amr.corp.intel.com ([10.22.229.23]) by fmviesa008.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Mar 2026 00:30:07 -0700 Received: from ORSMSX901.amr.corp.intel.com (10.22.229.23) 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.2562.37; Thu, 26 Mar 2026 00:30: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.2562.37 via Frontend Transport; Thu, 26 Mar 2026 00:30:05 -0700 Received: from SA9PR02CU001.outbound.protection.outlook.com (40.93.196.31) 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.2562.37; Thu, 26 Mar 2026 00:30:04 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Maq390+lqG2j+8Azoapi8XmPrmyeLQKm7gZnhOGLZ8W8RSPuAuopryw6gsMUN2o3Md0ZCjeTrs74syGKkx3kUAIVbEdhnJIHRLWE6/S68ajG8i7keBIktv5kF7FQlXGyiaVt0S3GFOOztgELIGHMBRWEnBzHKZqVrV10DEdBriX3BXuMnaKmq6YGMTJsEKvAtQClkcfU7z43cmDwqrKMNkeFPhYFJjdKSSatytgboOmuiAPXFIIo9b/EAmXVkrkqhxbYFn7CM40vMhqXjplxHkbgqPVcc/padhz0bEcfY722aoY93AdMN4Yie3VSauDcw3UoFHFwd4tp//sNajUS8Q== 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=gu9ydUtNOVj4676RbmWtvNEjhFwdPOujDEBA4obFDQM=; b=bp2NxCPQfsoY4WwEIi0QiOaE/yXml+iu14TT/tVH/Kl8q7urTiRz/q7KU+Tc74JAeXc8KNcI3nzuYyAbdS0Yj3FRIXctRzLbImf2kg7wNUPppZvl6qLVDjCmmo5RtoWNA8U2n9n65oswtM1k1VaXQ980u0gzPno+VarE+kRcYAQlGxWIgJPodM3AS3/xj4arqdBVu1hZMV7rdnKP4hLs5MjflRtfojNokoU4KD9x8yGmqcbkxg1MZbkcE6NUHq6fDhuRlrACgCYxV76pbgY66D/RNzPsbcGOUaM+3UWz3uuFZsVAiWT6O/Dq05gv+f7eg6Xx91Txs/DTg9tNbe+pWw== 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 IA4PR11MB9009.namprd11.prod.outlook.com (2603:10b6:208:56f::21) by SA2PR11MB4971.namprd11.prod.outlook.com (2603:10b6:806:118::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9769.8; Thu, 26 Mar 2026 07:30:02 +0000 Received: from IA4PR11MB9009.namprd11.prod.outlook.com ([fe80::eaae:cab2:868e:4541]) by IA4PR11MB9009.namprd11.prod.outlook.com ([fe80::eaae:cab2:868e:4541%7]) with mapi id 15.20.9745.007; Thu, 26 Mar 2026 07:30:02 +0000 From: "Liu, Yuan1" To: "David Hildenbrand (Arm)" , Mike Rapoport CC: Oscar Salvador , Wei Yang , "linux-mm@kvack.org" , "Hu, Yong" , "Zou, Nanhai" , Tim Chen , "Zhuo, Qiuxu" , "Chen, Yu C" , "Deng, Pan" , "Li, Tianyou" , "Chen Zhang" , "linux-kernel@vger.kernel.org" Subject: RE: [PATCH] mm/memory hotplug/unplug: Optimize zone contiguous check when changing pfn range Thread-Topic: [PATCH] mm/memory hotplug/unplug: Optimize zone contiguous check when changing pfn range Thread-Index: AQHct4abryaKSRoUW0qNNchDaIVkzLW7+GGAgAAJqICAAAMeAIAEZ1oA Date: Thu, 26 Mar 2026 07:30:01 +0000 Message-ID: References: <20260319095622.1130380-1-yuan1.liu@intel.com> <48b497e5-1545-4376-a898-f3813a6ef989@kernel.org> <168ab3c0-c44f-4d48-b7dc-33196b7ba6a5@kernel.org> In-Reply-To: <168ab3c0-c44f-4d48-b7dc-33196b7ba6a5@kernel.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: IA4PR11MB9009:EE_|SA2PR11MB4971:EE_ x-ms-office365-filtering-correlation-id: 41e91876-58b6-43c0-a905-08de8b097e26 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700021|18002099003|22082099003|56012099003; x-microsoft-antispam-message-info: Zm3ScK1Yxk5YB7VMVwa4bpYA7t6aFSyHXRpThfKwJTb3ziPYJp5jAVQNMS+qLNblsI/hF9sCTD/5SfLisvjFoBww7t8FMPg4ltiS31GUb4z9Lh+rMSKaylYdR1WrYmqysmh+gTik2gFvCvs+fF82NB3a66TlQCqLaKwSF+g8tI39PDuajv5ZfxKEBTR+sZQwCmFdFWnOb8bHjm7uWxPaCcUo3B0drJ60GJ/F8ZlTf19xqjY1RVuY4Id61b5rtfDGpABCTYosdvw6azdl7P02qHq5M5ZbQ9WbNhOOd53SrJ9JOiUGBU/Inmk2CpYDlY3PB+P2/eTpGJ46w8cfkMswUh9Is9DD59rXufd+cO9Var3ah9gkgFChYDYykj57hOdCQWr1Q+xwNfLGsav30eJLypuZf6HFiL6ureAZODnAdNVpIxfp3h+PTjhdfnqYeNsZcSdYu4xb84u/3nzq+w48ykK3YnF8dKWLThnSsB08PeIg4J2lWnCwvIvukreQmNbavlFknWQoh+t0WwgZ1z6mpYrls4USyYAJx/OyobIG/zCbTdSxYd+seN2tsIe4Ca6baRQn0Snsg2kOP4I5ZnKpqskJZf5Wo/2Q0zpSh1noqGbaZ2xsd+IBt4d4Ly4qHd9TGSG6OQ8R2iHM0o5/fvZHAgh1nfJd7cZmXQNoDpQ6lVAgg3Cp2YikJdK53+bW8GJNuN+AJYlyg84fr36pMAi1Yk7n2EVeEH+7QlRWBWJXdqFNzckFXu4DB/i3rkHMysB1idVjYB7hMt69R2yGneLE72BGxPC+MvJ8ctV5IH5j5Sc= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA4PR11MB9009.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700021)(18002099003)(22082099003)(56012099003);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?MlNzLzYyQ2pZY3pNRFRoWVpJaldPVUM2YVNFbnpxZWQ0N21MbGZQMDRaelBq?= =?utf-8?B?Y1oycWF3a1FSc21jZG50OTZncFFSZ0NvdG1SVndqUFBZVEZwZlRvczNJbmNX?= =?utf-8?B?dXhxbU10MW5MbU1PN28xaDZBWEllc3NUbnYwVlRBbVBKSUcwL0liU0YvZUNl?= =?utf-8?B?TG9wNDlmUXN3QnRld3pPMDBSblphZGZlQ3pXVWRTenFzSEtvSTAyMnlYNTIy?= =?utf-8?B?bXVFUmRmTWhleXJVTTVzYjh1ZXJnTFR1OTJlVHNXcEZ5M3EwaTJ6TFV3Z1Vk?= =?utf-8?B?Rk9mMnZ3Rncwa3Zpenh0ZjkybEdnYTg2VWUxSk5hNXJBTGMwVjhSTFhkVFhL?= =?utf-8?B?d294WE9Sb3prNklDVVMvc0RqejNvQnVlVGVJN0kyV2ozNWxqTmVRV1E4WXRS?= =?utf-8?B?NHZDL252d3Z2djFZbGZBREt0ckxZMElJdlViUlZYd1NjTXhTQ2h6WWpWbmRG?= =?utf-8?B?bkJGdlhoek44aU1QaEltOExmUHduamZQQnIzZnlVSWE2dGg5L2ZtRzJWNnB3?= =?utf-8?B?V1ZlRkt5QlM5cytBYUI4WTVpUEZtWkRCTnNnbHBleWlrbzRpYlFUVklMWWda?= =?utf-8?B?UGZ0aHhsNG9lV2FJY0VWWXRkYVYveHN1dzNweVBHWDN1V2xqcm5TYVlkNll6?= =?utf-8?B?eWsrYjB6K0NNQnA3SDB5UmZ0RFFiZlZCVFBzTkY4amdpUnlBS2YwdE00U0dr?= =?utf-8?B?VU5XaFIyYXFibVVjbXBtdjMrbkJjTGtkanFQR01zMDhiVWJXLzdXSzVEZXNI?= =?utf-8?B?NUgxbENhTGc0U2M2R05ZYlhoT0lVc1BveG5lVGFYcmQ5RU1ML1pMbWQ3WXIy?= =?utf-8?B?TU9TcHhjR3JLckt6OExkZHozcE9xbForTEo5T0duZG5JYXVLb0ZTWFM3U3lw?= =?utf-8?B?cTVTY3lGb2xpamgvZHRSbVRmeGJIaDA4YWE2djM0enFzaWlkNXBqTFlGRkJq?= =?utf-8?B?WGF0WVEvVWk0V3pnaDBUQXZYdXNBWVo2Z0ttbmRLMGdWN2x2Q1BFRVc3S2lM?= =?utf-8?B?cGpYM0lyUE4xdy8zbjdZMjVFK1pRZzY0U2VlZ0g5dTQzcFJndEgwb1dmbjNr?= =?utf-8?B?SU5ZM2ZLUFIrc2ovaGxiRGRTNnhlb2p3aHRGZnhnV3NwOUZvc2dFZk9qUXAz?= =?utf-8?B?ZWhrbGJQS0hkV3BTUVRLZTYwUjZFeVZCU3doYnJkck9pWjN3ajJRYVJBL2JG?= =?utf-8?B?TDkvckRUelJ4K2hpdm5JN3hHVFFjL1VINDI0RVpUV0lwazBHQVp5Q0x5Nlhx?= =?utf-8?B?a1ZzK2c2RjBibnJMZXhuYm1yeXg2RWlPVm5wVTlYTEI1a3R0V2VjL3ZYbXNq?= =?utf-8?B?Q2VHbVZ0RlEvR1RHazJ3YnhuUHdobHVhRkNKcDRyWHY4aXBObFpoZHJPWGlt?= =?utf-8?B?a1FoRlNBd0M5bXExL28wL0lReStjQUpHQmM4Y0ZYNWdQM1NOUU1Dc0pYajY0?= =?utf-8?B?d3I3a2tzSTlab1JVL3l1WUdjRnoxaXZKL1NPR2xmQUczU3gxNEd4dzRsQVB4?= =?utf-8?B?M0dZOVc4ZWY5eVJaK3pldzFTYnVNRkNpUlhocHorYkNySjhVVUNPa0Jlc013?= =?utf-8?B?Z25oM0xWc2YwSXZRVVVkbU43bmN1d1VDSFBPQ0pUQlNYb3Rpb2JYaURqcjZz?= =?utf-8?B?bWpQMWFXUXNWWlpZSHpJeHVKZ2RuMjlxNHZJUkkwVU1QWlViWUVZZEMxek9Y?= =?utf-8?B?MlpiZSt6cStsYVUyNkorTzJxM1dDbzM0WHpFaWdxSDEweHNDWEs5ZUdNbWJj?= =?utf-8?B?cGUzSVgvVzNXcW9RTkZoNGVWckNzVm9Ld1hZSnRpS3NueVFwZG81VGxUL2ln?= =?utf-8?B?NVAwRUJTbitaTHkwOENwaWp1QnJvR3I0VVdKcVByYmVuZFUyRzg3aTFZU1pP?= =?utf-8?B?K0s2c005SkxRQnp0b0FNbjltbnNFM1pncWxtNTduVEUrOEhpQlVqSVZjVmw2?= =?utf-8?B?ME9mWS9vcVg4SjE2QzJhMzg5aS9GaUwvUkZIV3FqMStnMGxvd2VHeFhuelhs?= =?utf-8?B?cUZvUHZRSE1jdkxHTjYrMEwrd0Z0UlVlNkJnbjFFS2lIblNiWnNnU2xBamFS?= =?utf-8?B?UXlZQ0VQeFF6L2s3UEoyZ2NTbXlVOTdqMkdRSThySExxNkRwUU9CMFBibkl3?= =?utf-8?B?bWUvZXJYOFFXMDRuTmx1S3NMMENObE1iclJ1bWphUmZHV1FkK0c1TlR5WEdF?= =?utf-8?B?RWZFeUQwanlXRjRYOHVJN0V6OHhDZnVKSHA5d3hVNlRHeEoyYmg4cW0vNVpm?= =?utf-8?B?TU8zNW16ZStUdzVHOXV5YWVqWTRKVmNvMGRIb3d3SjFLS1k1U3p3ZjByTC9y?= =?utf-8?Q?Lr6ZV0p8OwG2hU1C9G?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: vcidRomWMOuiNlGj1Znf55gE6+aThVfiRUNvXdF5e2VwQ2SnlwHlM6kGvfY9EiDzX/8kMC1PfkRBwUqEkprPfGmC2uSIfB8Uh+xxAFy5buHjwsNINX17kWqOj0bkYAgrDS2qCEdlB4/FAuvtkwyihduj3WlZW8X0LylogiwkXvPPDhW4YrKyMwB8zz8y+ACHpCS3/Fc5BguMIgajduiYhK36d4D1s8aFZBGKuO3W3a1N5WxL46zewGjLtN6HGlO2leHc9mygGNAxA1G4miNnmkfWyOGth9NmGKE6+f60J5cNHdZFi/CaG3K2MBo5vfOU1F0fqLfU5i9ETlSdneGgcw== X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: IA4PR11MB9009.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 41e91876-58b6-43c0-a905-08de8b097e26 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2026 07:30:02.0297 (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: G8rBLtiBX/Fq3IYMYktZiJsncSOhjhdwywkCvcNrFSmqlCb7mVjxlfyS3dgtLKD2bnA2UH/0LaPwUgirNiuWcA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR11MB4971 X-OriginatorOrg: intel.com > -----Original Message----- > From: David Hildenbrand (Arm) > Sent: Monday, March 23, 2026 7:42 PM > To: Mike Rapoport > Cc: Liu, Yuan1 ; Oscar Salvador ; > Wei Yang ; linux-mm@kvack.org; Hu, Yong > ; Zou, Nanhai ; Tim Chen > ; Zhuo, Qiuxu ; Chen, Yu > C ; Deng, Pan ; Li, Tianyou > ; Chen Zhang ; linux- > kernel@vger.kernel.org > Subject: Re: [PATCH] mm/memory hotplug/unplug: Optimize zone contiguous > check when changing pfn range >=20 > On 3/23/26 12:31, Mike Rapoport wrote: > > On Mon, Mar 23, 2026 at 11:56:35AM +0100, David Hildenbrand (Arm) wrote: > >> On 3/19/26 10:56, Yuan Liu wrote: > > > > ... > > > >>> diff --git a/mm/mm_init.c b/mm/mm_init.c > >>> index df34797691bd..96690e550024 100644 > >>> --- a/mm/mm_init.c > >>> +++ b/mm/mm_init.c > >>> @@ -946,6 +946,7 @@ static void __init memmap_init_zone_range(struct > zone *zone, > >>> unsigned long zone_start_pfn =3D zone->zone_start_pfn; > >>> unsigned long zone_end_pfn =3D zone_start_pfn + zone->spanned_pages; > >>> int nid =3D zone_to_nid(zone), zone_id =3D zone_idx(zone); > >>> + unsigned long zone_hole_start, zone_hole_end; > >>> > >>> start_pfn =3D clamp(start_pfn, zone_start_pfn, zone_end_pfn); > >>> end_pfn =3D clamp(end_pfn, zone_start_pfn, zone_end_pfn); > >>> @@ -957,8 +958,19 @@ static void __init memmap_init_zone_range(struct > zone *zone, > >>> zone_end_pfn, MEMINIT_EARLY, NULL, MIGRATE_MOVABLE, > >>> false); > >>> > >>> - if (*hole_pfn < start_pfn) > >>> + WRITE_ONCE(zone->pages_with_online_memmap, > >>> + READ_ONCE(zone->pages_with_online_memmap) + > >>> + (end_pfn - start_pfn)); > >>> + > >>> + if (*hole_pfn < start_pfn) { > >>> init_unavailable_range(*hole_pfn, start_pfn, zone_id, nid); > >>> + zone_hole_start =3D clamp(*hole_pfn, zone_start_pfn, > zone_end_pfn); > >>> + zone_hole_end =3D clamp(start_pfn, zone_start_pfn, > zone_end_pfn); > >>> + if (zone_hole_start < zone_hole_end) > >>> + WRITE_ONCE(zone->pages_with_online_memmap, > >>> + READ_ONCE(zone->pages_with_online_memmap) + > >>> + (zone_hole_end - zone_hole_start)); > >>> + } > >> > >> The range can have larger holes without a memmap, and I think we would > be > >> missing pages handled by the other init_unavailable_range() call? > >> > >> > >> There is one question for Mike, though: couldn't it happen that the > >> init_unavailable_range() call in memmap_init() would initialize > >> the memmap outside of the node/zone span? > > > > Yes, and it most likely will. > > > > Very common example is page 0 on x86 systems: > > > > [ 0.012196] DMA [mem 0x0000000000001000-0x0000000000ffffff] > > [ 0.012221] On node 0, zone DMA: 1 pages in unavailable ranges > > [ 0.012205] Early memory node ranges > > [ 0.012206] node 0: [mem 0x0000000000001000-0x000000000009efff] > > > > The unavailable page in zone DMA is the page from 0x0 to 0x1000 that is > > neither in node 0 nor in zone DMA. > > > > For ZONE_NORMAL it would be a more pathological case when zone/node span > > ends in a middle of a section, but that's still possible. > > > >> If so, I wonder whether we would want to adjust the node+zone space to > >> include these ranges. > >> > >> Later memory onlining could make these ranges suddenly fall into the > >> node/zone span. > > > > But doesn't memory onlining always happen at section boundaries? >=20 > Sure, but assume ZONE_NORMAL ends in the middle of a section, and then > you hotplug the next section. >=20 > Then, the zone spans that memmap. zone->pages_with_online_memmap will be > wrong. >=20 > Once we unplug the hotplugged section, zone shrinking code will stumble > over the whole-pfns and assume they belong to the zone. > zone->pages_with_online_memmap will be wrong. >=20 > zone->pages_with_online_memmap being wrong means that it is smaller than > it should. I guess, it would not be broken, but we would fail to detect > contiguous zones. >=20 > If there would be an easy way to avoid that, that would be cleaner. I try to get your points and draft below codes. +static void adjust_pages_with_online_memmap(struct zone *zone, long nr_pag= es, + long added_spanned_pages) +{ + if (added_spanned_pages =3D=3D nr_pages) + zone->pages_with_online_memmap +=3D nr_pages + else + zone->pages_with_online_memmap +=3D added_spanned_pages; +} /* * Must be called with mem_hotplug_lock in write mode. */ @@ -1154,6 +1162,7 @@ int online_pages(unsigned long pfn, unsigned long nr_= pages, const int nid =3D zone_to_nid(zone); int need_zonelists_rebuild =3D 0; unsigned long flags; + unsigned long old_spanned_pages =3D zone->spanned_pages; int ret; /* @@ -1206,6 +1215,8 @@ int online_pages(unsigned long pfn, unsigned long nr_= pages, online_pages_range(pfn, nr_pages); adjust_present_page_count(pfn_to_page(pfn), group, nr_pages); + adjust_pages_with_online_memmap(zone, nr_pages, + zone->spanned_pages - old_spanned_p= ages); if (node_arg.nid >=3D 0) node_set_state(nid, N_MEMORY); @@ -1905,6 +1916,7 @@ int offline_pages(unsigned long start_pfn, unsigned l= ong nr_pages, struct node_notify node_arg =3D { .nid =3D NUMA_NO_NODE, }; + unsigned long old_spanned_pages =3D zone->spanned_pages; unsigned long flags; char *reason; int ret; @@ -2051,6 +2063,8 @@ int offline_pages(unsigned long start_pfn, unsigned l= ong nr_pages, /* removal success */ adjust_managed_page_count(pfn_to_page(start_pfn), -managed_pages); adjust_present_page_count(pfn_to_page(start_pfn), group, -nr_pages); + adjust_pages_with_online_memmap(zone, nr_pages, + zone->spanned_pages - old_spanned_p= ages); Btw, can we introduce a new kernel command-line parameter to allow users to= select=20 the memory block size? This could also address the current issue. Test Results as below, memory block size 128MB Vs. 2GB +----------------+------+---------------+--------------+----------------+ | | Size | 128MG | 2GB | Time Reduction | | +------+---------------+--------------+----------------+ | Plug Memory | 256G | 10s | 3s | 70% | | +------+---------------+--------------+----------------+ | | 512G | 36s | 7s | 81% | +----------------+------+---------------+--------------+----------------+ =20 +----------------+------+---------------+--------------+----------------+ | | Size | 128MG | 2GB | Time Reduction | | +------+---------------+--------------+----------------+ | Unplug Memory | 256G | 11s | 3s | 72% | | +------+---------------+--------------+----------------+ | | 512G | 36s | 7s | 81% | +----------------+------+---------------+--------------+----------------+ And I see the UV system has already this (Kernel parameter is uv_memblksize= ).=20 I think if we can introduce a common kernel parameter for memory block size= configuration? --- a/arch/x86/mm/init_64.c +++ b/arch/x86/mm/init_64.c @@ -1458,6 +1458,26 @@ int __init set_memory_block_size_order(unsigned int = order) return 0; } +static int __init cmdline_parse_memory_block_size(char *p) +{ + unsigned long size; + char *endp =3D p; + int ret; + + size =3D memparse(p, &endp); + if (*endp !=3D '\0' || !is_power_of_2(size)) + return -EINVAL; + + ret =3D set_memory_block_size_order(ilog2(size)); + if (ret) + return ret; + + pr_info("x86/mm: memory_block_size cmdline override: %ldMB\n", + size >> 20); + return 0; +} +early_param("x86_memory_block_size", cmdline_parse_memory_block_size); > -- > Cheers, >=20 > David