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 4A2D6C46467 for ; Tue, 10 Jan 2023 03:57:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3F00D8E0002; Mon, 9 Jan 2023 22:57:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3A0188E0001; Mon, 9 Jan 2023 22:57:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 219D08E0002; Mon, 9 Jan 2023 22:57:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 135308E0001 for ; Mon, 9 Jan 2023 22:57:58 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 96B061A3334 for ; Tue, 10 Jan 2023 03:57:57 +0000 (UTC) X-FDA: 80337530994.02.637BEB3 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by imf15.hostedemail.com (Postfix) with ESMTP id 7828AA000A for ; Tue, 10 Jan 2023 03:57:52 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=NnYHANRY; spf=pass (imf15.hostedemail.com: domain of fengwei.yin@intel.com designates 192.55.52.88 as permitted sender) smtp.mailfrom=fengwei.yin@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=1673323074; a=rsa-sha256; cv=fail; b=JLtTK9FClv5yWret5lPMY7JB0rPKW3zukOEQp0wh0ixgszHzehtvZMeIB4Erhj3yFkks57 t+ZUvLpX/a7yPEwvAh9f9/8dIqKiTqcOGsBVbHTP3zLU3OrKGV+TdJkuFlRGtKQm1uYEx0 x67ockT3gUfzSYKG4Ix0OSPuktSyWpI= ARC-Authentication-Results: i=2; imf15.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=NnYHANRY; spf=pass (imf15.hostedemail.com: domain of fengwei.yin@intel.com designates 192.55.52.88 as permitted sender) smtp.mailfrom=fengwei.yin@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=1673323074; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=XpkBfMSJvgzjj8ufAt2A9KjciRZpYYwInWc3JCoNhMc=; b=37p9twQuHWQyZTdlzDrIea8IY1oP6Ew8HJW0ATgRl2cj9hj6SYy3i+4KNd7RsS7Lcm/p6h t6xJSaEYsVbAKTZ9FQYNMtfF7o7BQxuoVIUhGMvRI4c7dKbC+D75hU3tt5oSGU4RjPA2lV N1THhC6Dhgd7T3lQYslZze6rYW2OzDE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1673323073; x=1704859073; h=message-id:date:subject:to:references:from:in-reply-to: content-transfer-encoding:mime-version; bh=sAL/WeDVoFl13T/KiW+GL0+uYnpo1BcRnYzBMRTgs2Q=; b=NnYHANRYd2XylN9Ps5I01O9JVlRedSxh1BKDptCWAnV9qXYQGOlxjbXY JzgMYgxSw58T8SGJLzkmphcMoFdXxZkijaA6adighmW/u/eziUEn49CY1 UlWKT4MQnJOeT4M7oTzlAwlSa/H0ypHN6kTPEMhTOvzMBEDMCMOGUHUU8 zi8g2AoyjX6awI5x5tSfWcNmsde3zTcwKJ5gOz17xEMLUKVz9mVhoHkOi NtJ/o88ECQBzsg4MpYHT2mX9sGosSO7HRsZU+juBd8GRtsgaiZuzxnSqf f+xyFFk9t1M76aCKQ7nndW1xtNAMgI+L++rydVKpJUlej7PMmXPqwv/sh w==; X-IronPort-AV: E=McAfee;i="6500,9779,10585"; a="350274360" X-IronPort-AV: E=Sophos;i="5.96,314,1665471600"; d="scan'208";a="350274360" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Jan 2023 19:57:51 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10585"; a="606814155" X-IronPort-AV: E=Sophos;i="5.96,314,1665471600"; d="scan'208";a="606814155" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by orsmga003.jf.intel.com with ESMTP; 09 Jan 2023 19:57:50 -0800 Received: from fmsmsx603.amr.corp.intel.com (10.18.126.83) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16; Mon, 9 Jan 2023 19:57:50 -0800 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16 via Frontend Transport; Mon, 9 Jan 2023 19:57:50 -0800 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.176) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.16; Mon, 9 Jan 2023 19:57:49 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KO1sOw6unZBt5maKKWFmOO2zr/5pBCEGsqXTMTjyk8AogBi/4gkPK23QmndCbPgjAYzSFZtv+mOtoLZt2Rp5Khg/UZdacFjARMRdpSpOTAoBc3aOVlGYnBgsXJIOEbzb+gFVWMNg/t7v/PW1m0FDuN8zVyUZJI9d9K2dRd8co8yXfqUkFs4E8WYLlVRRYYR9veVNaaR7P6om78CaIq2dOJ0omXt9w1ncTI+YobC2XGo4Gg8odKfpH0Xicp6g9Zt2nwxhpCpJ1RYg/x9Kk3FS5XNJtsHJTGoeRAHLqe4dJtOxH2rz0fwlkKoeHfUkobNlln4q0ENlheC5bolfB4z7jg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=XpkBfMSJvgzjj8ufAt2A9KjciRZpYYwInWc3JCoNhMc=; b=ScQd7Y7qdGErvScqr1snoQyovoj9eRb5OA2hLWbVbtguvocKR7+BlWX0QVslLJ2pfx7I4BjGmc8xrXkSO3mLhMTck9Vrr4SYA440F5EjeDniYUWao1aRQkvQ5cgslleVeGDvnTfzrvNZBVREC2LQo1pPbLwiit5KT9Px2A2HYo7swj7MWSq1VmJF9YTICOILhGX9bmHf6CaIDGROxkG5vgHX/o63axMYRAC+V4xtK4T00a27NMkRunvOQxzX2l3zNllmvxzYNNFwPpLjKlFmnT7Fv4voelbqrhqX/fEuOyq9JqwjzdPKl6cGtnObdCRVqSG4FLcw9o/auDLANE6zhA== 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 CO1PR11MB4820.namprd11.prod.outlook.com (2603:10b6:303:6f::8) by SJ0PR11MB5771.namprd11.prod.outlook.com (2603:10b6:a03:424::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5986.18; Tue, 10 Jan 2023 03:57:43 +0000 Received: from CO1PR11MB4820.namprd11.prod.outlook.com ([fe80::1531:707:dec4:68b4]) by CO1PR11MB4820.namprd11.prod.outlook.com ([fe80::1531:707:dec4:68b4%3]) with mapi id 15.20.5986.018; Tue, 10 Jan 2023 03:57:43 +0000 Message-ID: Date: Tue, 10 Jan 2023 11:57:33 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.6.1 Subject: Re: [RFC PATCH 0/4] Multiple consecutive page for anonymous mapping Content-Language: en-US To: David Hildenbrand , , , , , , , , , , , , , , , References: <20230109072232.2398464-1-fengwei.yin@intel.com> From: "Yin, Fengwei" In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SI1PR02CA0020.apcprd02.prod.outlook.com (2603:1096:4:1f4::9) To CO1PR11MB4820.namprd11.prod.outlook.com (2603:10b6:303:6f::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1PR11MB4820:EE_|SJ0PR11MB5771:EE_ X-MS-Office365-Filtering-Correlation-Id: d54dc5d9-47b8-49cd-ada9-08daf2bed3a3 X-LD-Processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: oQTqr/bLfJx2FxZQqQ6laVWt8Zpkg5P9b4Rt1RSee5zR6nHqXc85c7ZgIqQmhhB9YEjq2csAcrKd3z1EnPWKncO5WMCysitqcruOHNQwc5NWl2QcSs6wiW9GbQSAdnZSkl0hocbU8pvPu/fAr4SG8q6R8TlNUMWiSicDTdPgspA5OvUFQMHHoH/LEEkDKDPYqUnxJc4SHW9JPz/vNr7HWl5oIHoCG2fFSEnfEFX963EHGjdRg1szLakzcvSQAvf3FpRAmpJqsez9hGqtE1CyG5o8QupfH5ADgZuc9zoFoxedGBoLqyHoem0BhfySrqcfWAYKU+KRJTw9qwCzeShYM6mlmGU75SiugsimB2MVx/Zba7DDgxgF9hs8o25OTR9Gmq9IRCXum0tfz4aLV8/FV6T3AWYTelQeHM2+PUIPV8TaXf7PCmG0OUxr++hcK2Pt/F9/VxDG7CGdipxjeqaaTGg1c5U8ny0hLtyQ2wQcQ2NWqguM1UeuTw5BBwOZZDNJZvWbpazlufVOeY1FBfGB4HvHQqGMl7qCXQeZyAKFG+3pQDG2MWmXhdN3s4qB7Mc/77nTvL4k4/e9dENXWvZF9vOYJyE+AO8qUTUjITgS9sa9pGuKEy4sHtBYkvwF3gVz78AgynSM6gTyedauCle137D0s0VynSnX+ToeL3lhDiM+coo0IUV5soxNgWercVkyDEqyaDRIEA91iXTcGAEA+Sy09sON47/fcEoHP66m4/dPH0XpLg9+GVFAMd88k6+m X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CO1PR11MB4820.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230022)(39860400002)(396003)(346002)(366004)(136003)(376002)(451199015)(478600001)(36756003)(86362001)(82960400001)(6636002)(8676002)(5660300002)(31696002)(7416002)(66556008)(66476007)(38100700002)(66946007)(921005)(41300700001)(8936002)(26005)(316002)(6486002)(83380400001)(2906002)(53546011)(31686004)(6506007)(186003)(6512007)(2616005)(6666004)(45980500001)(43740500002);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MHVPV20yZUp1S3U0UUJyaTBUT3pIRXNZZjBzR3NNaStGcVhFZlNKUmpYMlJC?= =?utf-8?B?K3dmK2djbEtKT3NLKzVvcTRRNmFvY21WZURrTkVDR0ROSGVYUDlYak1ZTG95?= =?utf-8?B?L0JjRC9rY2JYYUt5U1RNdU9SOGo0cVlSL1hURjhvMTMzVGloWmxNeXA4dEcz?= =?utf-8?B?MktQaWFVWlJqcUZMUjl2eVdTYmFLR0lxaDdIWkFFQnY3YlE5a3h2bUhWZUI1?= =?utf-8?B?U1VJM0FFOGt0alZTVWc4TDJJQTM3VDJ3Y3VSYjlpSGVzcldCTjZkWUFqWEZQ?= =?utf-8?B?aUR0bWlXU2oxdVRINGx5MFZHYnU3YU5UY3FFa3NDTjVFVnpqVDV1YStIZTNr?= =?utf-8?B?STVqN2tBUm85M1NNb2oxT3lJaFdvTWVDYTNTVmlIeHBZS1BxQTc1UDF5R3Vx?= =?utf-8?B?U2owRGg2alY1TFRDMTk1T1NETWdGTkdVV2ZsMjBYWkZvaWdHcWhabXpvUnFz?= =?utf-8?B?anlzV3F2RHB1My9FeGpCZ3l4YTltaG1TaEwvM3o4NmJHQ0ZZbzErQlpoaklO?= =?utf-8?B?bXMrbDdSWGFyQzkzSWFPbm8yb2VtU291RFg1MXBaUVMrMW5oK2kxdFdnNG1C?= =?utf-8?B?b016VDUyMmU3dGsxTzY3SC9NVE8wZ0Q1UUo2S3NCWTkrcEtUOE9nWXNqNmxX?= =?utf-8?B?VHVSOFlISHJHc1BrMGR4dFo4bFpkNDdWV2VFQUZyOHpRbmh1MzViaWtrMGFM?= =?utf-8?B?MUpicStudGxITDJvSHpBbVRXajZJbjNGc2l2OEdqUTVOK09CRkMyUGtvdld6?= =?utf-8?B?MWh5Q3hCRTE3WnBUVVBKZ0RsMlNDaEgrN2xJOTM5LzB3OXhpYjJHR2Q1SXZM?= =?utf-8?B?THdIUUJ4dHRic1k3S2JoYmJ2cnFGT0N0ZGdaRjNRUUNZaHZoKzNUSlJ2MTFG?= =?utf-8?B?cW8xdDE2cWdkOWlWbjRTTStuYUlSRjhxbm5kajNSc0M0SU53elVtcU9mRUgr?= =?utf-8?B?M21OMzhCbVAxNjhIdkhGdXJncjFMZWRDeHdtazBHTU9IMEJ1ME5vb3dKYnhk?= =?utf-8?B?WDhaOEtyOHl1ZkVVUmlEQXIyUDhrbVl1UHBKU3pQck1KL2xMSjRJUVZVREp1?= =?utf-8?B?Q1VTSmRaU2ZkUG5iQjVLMllBWUpHTXNEcW5MNlhZVzZPZXRZRmZmcFpqVVZx?= =?utf-8?B?djdCV1hsQzhNc3MxSEV4QVJUM3F3UUtMVGowRlZ2Y25mWG90c2RiWlBNaGVF?= =?utf-8?B?Sm5UQ1hHNHVzWlZvL1ArMmEwdWI5MFB4ang0cCtQVDhaemFTQ3MrR0FnZVRi?= =?utf-8?B?WkhvbVErbURHVXpMbWlldXgxYm0wK2RMeURpSzBGTi9HUlZJc1R6ZEdqZmQ1?= =?utf-8?B?TjBNMlJRTkFwMExlWGFuMlBCVmNuSHJXTTduNytXN25HNHhnWUs2UitxQkJv?= =?utf-8?B?SW5QRG5DSTVFUkJLbm1MRXBOZytJeks3MUlEVjl1ZkNHRndIZ2p1QmhMVURq?= =?utf-8?B?emhXVmQ5ckxCZ0JUQ2VMOGFkSlZKazVMSHFXZWpubVhxeWEyQy9tRzdiN1o5?= =?utf-8?B?S1ZvQnp3cXdqOEZwMm1YVk5ndVNJZ1RQWnJzbDd6YkJqc0VmRXh0aThCYSsy?= =?utf-8?B?N0xMS09JbXJXK0ROMnNzTjI0TWJUa054YXJGaW4xOEptdHhWNytONmZjUHdF?= =?utf-8?B?QTFPTjB0UkRJNnpNd0lPQUxxMGdlUVdpNjhpRmpyT1RCcmtiSDcyK0Y2NEpV?= =?utf-8?B?aHVRenRnVUVUNVMwRzNUVXRmZlFvNlRNODZKYTJYeUtsV1VRczc5QmtGWWdD?= =?utf-8?B?emFlajAvbTlCRU5oek1GQXozUDBwd0RLVHp4clpEM3N3Ym5LMlZrTkRkaFFN?= =?utf-8?B?MC84NnpvaDY2TjlhUE93UzNqTUpnZmhJRXM0bStQbzhmOG5mSjA5SllYaDJJ?= =?utf-8?B?Z2V2WlRzNUd3eU1BWXVJL0pqUCt1WGdsZXhoRVN4NmJ0U0J5NGVnZVF3SWRJ?= =?utf-8?B?WmtiOGdMSWRtL20xSy9YTHFvVVU4dFE2WHFpRlN4U3h2T21MakpFaHZIUStp?= =?utf-8?B?SWxJSm9INmdWcVFQMjQvMUxlTWJBbEk1Vk8yc3JBNmY2dzRzdjVaSDJPamts?= =?utf-8?B?ZjJ1b2NkcTRnU1dtdWs3cSs2MWRRMG5tS25oN3E4T2FiTWt4MUNuTGJML1Jx?= =?utf-8?B?eUtlNkFCeGNaaEFuNWJteUg3TGVDSDFZQ0JrRVBDL0x4ODhDVVp2ZCt1OGwz?= =?utf-8?B?b3c9PQ==?= X-MS-Exchange-CrossTenant-Network-Message-Id: d54dc5d9-47b8-49cd-ada9-08daf2bed3a3 X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4820.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jan 2023 03:57:43.6024 (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: LLj3b+I9+HvDsHX5kkWp6Np1Qfx0Rqj5icrsRnfCdbHiLhTaKSzNq0eKVKi6eeVsMFiMpXL+qiAwnEiuCkGR6w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB5771 X-OriginatorOrg: intel.com X-Rspam-User: X-Rspamd-Queue-Id: 7828AA000A X-Rspamd-Server: rspam01 X-Stat-Signature: 4g53y8437nqxj1648wbhytau8356nuak X-HE-Tag: 1673323072-455987 X-HE-Meta: U2FsdGVkX18di0zX2YmatbJfIr2HHfbpLTcF3sngJfnW/yy4SQuAPRvKe59kQsQp5yOVc+npFBpAf4zNXhutVvzyyfp54ghV0bPUKbutS3WFYQ0IP3jPzYU8HOU33Mc1gRkmdRGchbrSzccmzJ3Ykv4TqakyxaakI1ZOkAI8261zhPyw75i10v4HbcakH61ro2zSz0SKkWOGrWMFABe439jgdmoS736SS4X/0YNBrgUOvmmT3YZ9+xGDQb40u0vkxGgtODb2vWOdlWV8z6W4fnwaqDqZPcKKMkdFEEO53uBJN+bue2gReXupRAKD5/L0KIgrXIDqQHbMtHdE8rvuJjEIUss6nlgslXoV+EoDMY8yFhnO80ha7z4euPG4C6yW0mGvaCLBFcJAYruTj4zCJ+RB4kIOmFUvQ3Nu0/NVJ7ClLkSoOoF+Z5wWjCayjiKtei2sZNjzBY2XETQ1IsZBnUYvgKZ3m7oGZJZHP6AGJQ4rrROUsDDXuKVr7ykq3UU5gkwDl2Jx/fjbO6iocZ4xaNGNq4P4yfd6BJmmGzrkC0Tz4rYgXCkV70cKiznnTuzIc+9/rp5+AAhS5OcXf4T6B4BYT0i19iYNyBZjdZVpL9/vHkKwlrW0tzur2YXTxz34e4eNorx2sbY4W1TKwISGp5zdi+SU1U8GIb+1psLTHGKPFCDEGPDLCp5OgQkoZ9dWFuJF8F+kBwJUsW4ldWu49e93vR7x7YdjYEKlwGnGG9hgYjI3G35DU1xlDKN1EwHoGCHGEKX6f5XwCDYqdOs2vlwSQVERKz+C1RSxa+xZ+KCxiwCArW0Qg2CX7rMCKrVyTaTqsrmEXU48T7OX6bHiMkHtnN0gDs1x2r62PN7uJxI0FYGn7lu0hg+vsCuM/IiiO/h4OroJqWxuNaV23/BVnSrkggadJBFaXiEX2FYuZZ3mV8RjTkk2I2HuA0wuoo+g 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: On 1/10/2023 1:33 AM, David Hildenbrand wrote: > On 09.01.23 08:22, Yin Fengwei wrote: >> In a nutshell:  4k is too small and 2M is too big.  We started >> asking ourselves whether there was something in the middle that >> we could do.  This series shows what that middle ground might >> look like.  It provides some of the benefits of THP while >> eliminating some of the downsides. >> >> This series uses "multiple consecutive pages" (mcpages) of >> between 8K and 2M of base pages for anonymous user space mappings. >> This will lead to less internal fragmentation versus 2M mappings >> and thus less memory consumption and wasted CPU time zeroing >> memory which will never be used. > > Hi, > > what I understand is that this is some form of faultaround for anonymous memory, with the special-case that we try to allocate the pages consecutively.For this patchset, yes. But mcpage can be enabled for page cache, swapping etc. > > Some thoughts: > > (1) Faultaround might be unexpected for some workloads and increase >     memory consumption unnecessarily. Comparing to THP, the memory consumption and latency introduced by mcpage is minor. > > Yes, something like that can happen with THP BUT > > (a) THP can be disabled or is frequently only enabled for madvised >     regions -- for example, exactly for this reason. > (b) Some workloads (especially memory ballooning) rely on memory not >     suddenly re-appearing after MADV_DONTNEED. This works even with THP, >     because the 4k MADV_DONTNEED will first PTE-map the THP. Because >     there is a PTE page table, we won't suddenly get a THP populated >     again (unless khugepaged is configured to fill holes). > > > I strongly assume we will need something similar to force-disable, selectively-enable etc. Agree. > > > (2) This steals consecutive pages to immediately split them up > > I know, everybody thinks it might be valuable for their use case to grab all higher-order pages :) It will be "fun" once all these cases start competing. TBH, splitting up them immediately again smells like being the lowest priority among all higher-order users. > The motivations to split it immediately are: 1. All the sub-pages is just normal 4K page. No other changes need be added to handle it. 2. splitting it before use doesn't involved complicated page lock handling. > > (3) All effort will be lost once page compaction gets active, compacts, >     and simply migrates to random 4k pages. This is most probably the >     biggest "issue" of the whole approach AFAIKS: it's only temporary >     because there is no notion of these pages belonging together >     anymore. Yes. But I suppose page compaction could be updated to handle mcpage. Like always handle all sub-pages together. We did experience for reclaim. > >> >> In the implementation, we allocate high order page with order of >> mcpage (e.g., order 2 for 16KB mcpage). This makes sure the >> physical contiguous memory is used and benefit sequential memory >> access latency. >> >> Then split the high order page. By doing this, the sub-page of >> mcpage is just 4K normal page. The current kernel page >> management is applied to "mc" pages without any changes. Batching >> page faults is allowed with mcpage and reduce page faults number. >> >> There are costs with mcpage. Besides no TLB benefit THP brings, it >> increases memory consumption and latency of allocation page >> comparing to 4K base page. >> >> This series is the first step of mcpage. The furture work can be >> enable mcpage for more components like page cache, swapping etc. >> Finally, most pages in system will be allocated/free/reclaimed >> with mcpage order. > > I think avoiding new, herd-to-get terminology ("mcpage") might be better. I know, everybody wants to give its child a name, but the name us not really future proof: "multiple consecutive pages" might at one point be maybe just a folio. > > I'd summarize the ideas as "faultaround" whereby we try optimizing for locality. > > Note that a similar (but different) concept already exists (hidden) for hugetlb e.g., on arm64. The feature is called "cont-pte" -- a sequence of PTEs that logically map a hugetlb page. "cont-pte" on ARM64 has fixed size which match the silicon definition. mcpage allows software/user to define the size which is not necessary to be exact same as silicon defined. Thanks. Regards Yin, Fengwei >