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 06181C5479D for ; Wed, 11 Jan 2023 06:12:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6832B8E0002; Wed, 11 Jan 2023 01:12:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6337F8E0001; Wed, 11 Jan 2023 01:12:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4AE558E0002; Wed, 11 Jan 2023 01:12:47 -0500 (EST) 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 3884E8E0001 for ; Wed, 11 Jan 2023 01:12:47 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 156ECA0769 for ; Wed, 11 Jan 2023 06:12:47 +0000 (UTC) X-FDA: 80341499574.26.5097943 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by imf03.hostedemail.com (Postfix) with ESMTP id 4A9F320009 for ; Wed, 11 Jan 2023 06:12:43 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=YcrlYYfI; arc=reject ("signature check failed: fail, {[1] = sig:microsoft.com:reject}"); spf=pass (imf03.hostedemail.com: domain of fengwei.yin@intel.com designates 192.55.52.136 as permitted sender) smtp.mailfrom=fengwei.yin@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673417564; 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=69hBjESsD7WwxOwqmsmlYzvLhONeEvCPyxDxPNjMCrU=; b=Mkhq93RI+CyQ72HfUKvsushcowCYSXYIHLTFUBWSuSzNYvzmdM99HyEhdR3AdGgCafXJtT ZpQP+4A/VE88er0v2625Zv5RL0bizEVHZhxFzxHWMANDw+f8a04U9fPggKJ5sadLketOOR QLHfgI39kctl6XxztzAWvufERJA7uaM= ARC-Authentication-Results: i=2; imf03.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=YcrlYYfI; arc=reject ("signature check failed: fail, {[1] = sig:microsoft.com:reject}"); spf=pass (imf03.hostedemail.com: domain of fengwei.yin@intel.com designates 192.55.52.136 as permitted sender) smtp.mailfrom=fengwei.yin@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1673417564; a=rsa-sha256; cv=fail; b=tjp90AE6bNGpMDy3GbrEai+VIGmjJHYxSqBH5yx+Kyl6ObXDZKlyXpc5nQ7ixcxJdT1rtA RjxGCungnDU7heujCjPS76ycCaQhMTxTfKwkPT84fRW7qlxPP963rltRN+eJUb6xkGtNvK x6SfbQHJ5V01v+B6jMBLP/6HspFZ5Bk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1673417563; x=1704953563; h=message-id:date:subject:to:references:from:in-reply-to: content-transfer-encoding:mime-version; bh=39dbncoj/6VTg/NbigbzuDU5LOgqT8MOzV9XlcepWew=; b=YcrlYYfI0PwlRZYHo2raSFlsLucgq6SUMqEQVsKq43j+DlHBcHpuMqCA q0j/iF/lkmopd4mK5gwjOQEf7OjNCsDckqaJxMtCcPqQZdtb/Q7gKnqqO VvWOHvmqBYsubT9Fuf43G1xZpEv4TGbwl8R0RT8DZEy2CGvF0DCDKMHqp 1QUvE4FGN+8S+/F2WpYge/iKCPfxICP8SZ2yA+BR4i5KOuYFeLyeV17re xxML16/cla3jg2bsaj3v0e+MleSKW0vQPNF/w+zljhEdXQG0IRXdUcyaM eT5IaN+btjjrKylAlHDO73cZYQz1YFpLxqkw37yjbJ1kfrShYuJ3QucoK g==; X-IronPort-AV: E=McAfee;i="6500,9779,10586"; a="303037135" X-IronPort-AV: E=Sophos;i="5.96,315,1665471600"; d="scan'208";a="303037135" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jan 2023 22:12:41 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10586"; a="725796465" X-IronPort-AV: E=Sophos;i="5.96,315,1665471600"; d="scan'208";a="725796465" Received: from fmsmsx603.amr.corp.intel.com ([10.18.126.83]) by fmsmga004.fm.intel.com with ESMTP; 10 Jan 2023 22:12:40 -0800 Received: from fmsmsx611.amr.corp.intel.com (10.18.126.91) 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; Tue, 10 Jan 2023 22:12:39 -0800 Received: from FMSEDG603.ED.cps.intel.com (10.1.192.133) by fmsmsx611.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16 via Frontend Transport; Tue, 10 Jan 2023 22:12:39 -0800 Received: from NAM02-DM3-obe.outbound.protection.outlook.com (104.47.56.41) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.16; Tue, 10 Jan 2023 22:12:38 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MOi3hqxQpU/cq+Akd1vaAk9RfQKdvItXMhFqaWTLfHeU6+/ZaCTlxmadbeMFrtNzYuMrYkpFOqnbKW80LpGXAFb4odYn91Gcdq4QhuAFF/IRfvs07ttyZpEhDz/8qh9Q3khKZ62Vd2x/7ifh12sF4r31T9qIAP/ycsYEe9cZP+TFFZeCRSpo3ov+vMT9V/QbZvUZdqm8bRkj38gZ4WZ51F0Xz72XkyTvejn/mG9QaEtegkIx0B+OCPxXeKlfCMJlFnK8pix8Ri4oJ+IvSPBLUASF7F1N8qjOoEn6qs+PXD5rjOnE8IThXgWZEbq8G+LgPhanvartL9UaxvuY9qxwHg== 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=69hBjESsD7WwxOwqmsmlYzvLhONeEvCPyxDxPNjMCrU=; b=A8FbeIEJnfbGdDKIC9GJd/C11xo2kK4M295APVxlqH9fSEU5Nl8+qSgDK+Fjyxm0c+gCbFhYHT3SU9JJC0XF+pujd4U3fZkeNjeGc4wJsCWdtu1Vtb5IlGOR2++BqosZxvcp1mRADkUaauZwAbh71uPB8KvfBAFfW8Mt1Bnsavvecl+JvL7ux+V6REHqP8eVp5Da2tK547V0skXDExTygg+wexYlgH5BJxFeaK5YNDp/yBw60VwWJ6PGcEHdzdbWAlmSGuRj0qEwmg7uv9ON1F+INv6OXRKzCov0ZAggVr7A/SeYXKHBT0F7oOG/3Ppt6sZ94Kz87KlsUrKt3/oS9A== 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 SA1PR11MB6967.namprd11.prod.outlook.com (2603:10b6:806:2bb::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5986.18; Wed, 11 Jan 2023 06:12:29 +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; Wed, 11 Jan 2023 06:12:29 +0000 Message-ID: Date: Wed, 11 Jan 2023 14:12:14 +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: SG2PR02CA0015.apcprd02.prod.outlook.com (2603:1096:3:17::27) To CO1PR11MB4820.namprd11.prod.outlook.com (2603:10b6:303:6f::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1PR11MB4820:EE_|SA1PR11MB6967:EE_ X-MS-Office365-Filtering-Correlation-Id: 1e66597c-e559-4567-3445-08daf39ad18e 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: mWgZB28/hhJg1HhsGhf5WH53ct8Ptn5p8m4bvdldIeo+kLpG0dyMCGcP70Z3TcyYRSlfzpaK11so3juP5r9NgHLpURQ7n1hujsr0a31EZ73pawpmsqI1u+cMEVbVgp7SffB7m4K9AROhEWnelS1F5Iesz5/CAUng4vAHdysAK6AKXLUW/iyskxzeRRRXPlzOCJ3L2vFPqpaqjP9SccUIT9Xja03cJQcZuVFLJcyD/x8MV2nSrXclloFbPRlI/Dks1xxeN9iN4nAW+Ha6/gDXO6D5nYlN9X8gIcX+EkLt/++LjRsZxCk0p7Xz6DBEv5Y03WMtznjK2qO3uP13YMhIYujjT42s7E3TvoMNTv4G13wjxAypUo3DJuyXSuqLHA9UNwAbXkegcjGRXnqGsI/UN27JDYoPOb4fP6r6XaA9hBf+MRrR//TQhJhWjBEox1lA98B1GsByMqxVkaFxP7jNlDOtkl4HzGPArebDSV0vApeRQbRYZsWM9MQaJDt81bq973l60Cs4zJ5VOxJddlpNHm4SKHCZ6M7WMCLwAqVKbvGcbYQx02oHYIk1OO8dCvwA4/QX9LvK6eX5lMS3B3mYUkEi9zQI9ZRa6MpP1Jgkm63zGbWwAMfqSIuQ6SpIT3K6Buk8PNyMxif/4vaDkE1wjlM2Okc2s9Z9FxfIgV1mceJqfNNDTb8lyfXkLBRTg5sjvlizfSMLYdfkL6boWFYrJ/pM23ObnDBLou9bz6b1qfr8VKdQYAnP0g7iVSuvcNCH 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)(366004)(136003)(346002)(376002)(451199015)(53546011)(31686004)(2906002)(6506007)(6486002)(26005)(6666004)(6512007)(478600001)(186003)(83380400001)(8676002)(2616005)(36756003)(66476007)(66946007)(316002)(66556008)(6636002)(41300700001)(5660300002)(82960400001)(38100700002)(921005)(31696002)(7416002)(86362001)(8936002)(43740500002)(45980500001);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MlU2MXlqR2QwdlhuMlJkRFFEWDVHRVA4ckNHNEM3UzJONHdkNmFjamtrcGF2?= =?utf-8?B?MjhNNzQzU1Nsc2ZsbE5mazZ1M08rZHVaUzhCODAzZEY1ZGJrWmFpTUdzM3N1?= =?utf-8?B?V2ttcHFEUzQ2MXJ0RDVGZzl2OXF3RUpxeEttck94cGg3eW5uMTdXM3J5Zzl6?= =?utf-8?B?ZUJqMkZ5b1Zha2hQclFQTW0ycDBjQ2MyTTJzeDhlQXZtUzh4WDVCUWtuTUVI?= =?utf-8?B?dGtLL1JucEZ3UVVEMnBoc015NS9zMEwwRHF5aGRUYU53RTZrK2o0RCtiUTJq?= =?utf-8?B?Mm1TdmdVZHJjT1owcHAzSGVHVitNRk1GalZsakwzTksyeG9tU2lLMUxYdkZ6?= =?utf-8?B?SldmNkpYaGR6SlRPb20zaXN0b2JsOVo5WW5EeTNlYTh2aWw0ZUJsS2NWR0NU?= =?utf-8?B?OUhaa1BMNXdoTS9OYWI5bFc5RGViQVdLS0gvang2TDZqbHlsbGlQQ2FweTky?= =?utf-8?B?ZUtjVCtNZFIyN3cxQno4N3I4ZVFGcFg5ZlJ6WjVOY1YxQ1k5c2VsR2k1VmhT?= =?utf-8?B?NVZiS244NkttZkNyVnZ0REZ5bU12SXV1ZkxEZ1BmcGJQQTArWnpQaDhKOHJq?= =?utf-8?B?MDE0UVY2SGU5VFA0dXN2T1E3d3Jlb3VXNG5EVjZlVmxSelZRRGt3dzFyTG1z?= =?utf-8?B?ZmhDMnM1dFkrb29mNWdMUjdUcTBwWGJwNUdyTWwrOEdUMUR3V3FKV01zN3Vj?= =?utf-8?B?VHcxcEFUMmZYQTI5NnFWM2tlaGduMTgvYXc1V3pmUDdRWVdZNTh1dU1EcUhW?= =?utf-8?B?QTBHd2pJUVVhQlQycmxUWC9JcWRyNENsa0NscVNuMzYyL2wvV2dqRWhRQXNE?= =?utf-8?B?S1hwUVV2UGxqaVp3bEQyL1lKbHRMcU9taTFZSDgxR2lyelB1eWN4WSsxQndp?= =?utf-8?B?bEQ0akViaWsxdGVVWUxLdE9EZ1RLelhVL1Q3bzBJY0MvVEhMb0pUTzlzbXVv?= =?utf-8?B?dEgrYTQxVG5FRXhQbW1YTENGQU1vK1Z6OTVidkMzQU5WVkZrMXpjWGNkcXlP?= =?utf-8?B?M1RUWGthOWtYS0Zhd00zenJ4TkNUNmZEU3BOSStITTdMaVJ5UUV0T0tLUGti?= =?utf-8?B?RTVyb3Z5TEJpUUlBMHFqZ01pcXpZK1oxZWxOMXN2M2w3WThnT2owc3JZMU5v?= =?utf-8?B?bXNyczJFVzV1V3E2em5HbkVnbjJ5Z0E4R0tRbVlKRk0zOE4zMEM4RGFMOEhN?= =?utf-8?B?Rzh6TzVKRDAzdi94M0tMQ2lDV0hzbzljdjMvOU1KVkdoREJlTUQyMUhuZ0J0?= =?utf-8?B?UnVaOTl5dWpRdk51YUtDMHlBbFNVbGc5MG5HSE9hNk90Yk0rYVE4RzM3amtp?= =?utf-8?B?Um1TWUFDSGZXdUZSbnYzNDJGSGdxbUNIZXFYM25XeU83Q2lJQ3UwcWxxOGxR?= =?utf-8?B?cE9TTHF1ZzJrVWtyWXJ1LzhBTnh5aHlCQVpWVm4wSHRRaTE0NC8rQkYyNkJi?= =?utf-8?B?MWU4ZTlTekNnb3ZBQm5QZDZtNCtlRkZuQjFHZk1PUSt5eENZczYrNnFNaUZr?= =?utf-8?B?VTd2Y3F6WWU4azIrUXk2RmZuRUVTN0Q2NElISlpYMEVIbzkyeUNiSW9xY3dV?= =?utf-8?B?NjBtNVJtUVc4TDZCekMyMmowbTVRWlRhZ1pFUmRDN1lyMm5ZY1gvY1E2emto?= =?utf-8?B?R1NyWWRtZlZIZlBUakJlWUlWTmlPTmx5akpKS2w4SS83V3lBc29ZYW42enFu?= =?utf-8?B?bHZTVzd5cHZGUGRIQlFzVzlDeTAzMkpDVGdBZzVJazNrcjlGczNWYmlGZWVp?= =?utf-8?B?OUtmSzFGbVJBMTAxZ3B0REptUnZqckJRZ0VQRlg0MWY0ek1IU293dUFuaHlV?= =?utf-8?B?ZWZKOVNCZzZFd1RXYWY2c0k5ZzVTWlpQelRWV05GM2xOdGZmTWJHc0dvU1gy?= =?utf-8?B?NThWWDRQSXBHS2Jac09acnNvRGNreElYNE5QNzFsQmw5dzJMaUxwa0tPVFVQ?= =?utf-8?B?dTBSdGR5ZVNGcWowOHpaVWw0VktjU013RkkwRTRSdGRBRFNSVEZUVGdJeWti?= =?utf-8?B?MS9kL2NnaXY5WXB5OUFlMDFSTCtzVkowYlEyT2hpd1hIR0hoZ2FXZ0tmeDR2?= =?utf-8?B?U0IzdWEvOUsycnF5b3pwM1ZRTUNYWEVSSjFxcjBRdjFYMS9DN2lweXZTMW80?= =?utf-8?Q?GA19OiRZv1YNyg56xsDovvl1f?= X-MS-Exchange-CrossTenant-Network-Message-Id: 1e66597c-e559-4567-3445-08daf39ad18e X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4820.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jan 2023 06:12:29.3867 (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: oF73VgkzhMCmZvLMJDAONufPUZNl6QC40Mi/9X7/QscuESKrdYZcb59+WqE01QR2zeq0zYoAVlzXGLGqlr5LjA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR11MB6967 X-OriginatorOrg: intel.com X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 4A9F320009 X-Stat-Signature: 8y9dju5fwytz89och7sjz8fdg3q11f9x X-Rspam-User: X-HE-Tag: 1673417563-244352 X-HE-Meta: U2FsdGVkX1+26C783eqo14u452M8hpQK9a7XNn7tefODo5SAZQ47fFUaqEgl60uagJ7t5SXhvX/M1647U8DKH1v8K734wQqqsZWOuvd/j8IRmn2unvC3UU/3KtBuALGCg1v06SKM1II2yeATl1D2m/Wsh8Pi/LnurjaczVgWc2dch86cqhkflGaVxQPDopcOQoxGzp73qBdg8joE1htPE7JJD4641ysy7sL5stjG+EcjnmiKYGXgaXganAcrUmaPpKscNmNKFy8fkm/riPM9tl5UinXR0C9u8SDYzrltt7ic5HgqGLmiYfRYQ62OcUnrg1RecfxjvOpSAtAFHD9ymAIAK/ObzxALW2HQZDuXy0Q5k63U/tJiT/Iap3qYR4sYd89CkjvOn3e94yduWLdnjqn4toy3ESqgcZfhwr+EXdtIsUvIAidhqCZfUsXDGXecwAvNC2ljl53BQmJIrcYidXW0PhOjkvbMd27n+zPAI3kTa4jq3/cLipcdseUliwTZ9D2LmUCiQbyNGk/zvXhIYFM+Q9GwY+ypd7HV/wNhSKSjC4IQHGfZoe1nP8Ac98PcoAtnFZlgQ6OLqIvsh4iBnSo0Mu2av2rK1tcPvRo0DoPxiFlr2z5lpK43nrUnKlB18aYd5fkZgn/5tWcBn4a2J7XhmPwnW58Ks87PIIt+AmSoJeahNaLM105+arcG2k+PB1yN64/M37+O/teon6GueGMP0MKQN0+OB0kzmOTyZIt7JBKLXg9oFlnYxAEy90QsoC3s/+wdiRsbTVbNUnVoohmS3jrXCIgAL2yx+OkyRt4qUzoSkQrk35kmS5b6PoQw9lE5aagr5eRnlDiRNH0owmnYlu+F+SOpKjTv6fGOyQl960y2wGqc1hj1MMZ1Nk7NpjDq5GlkS3KWiZYHO/8ZXi9vBrQ6iNnFK1dB6umT9HGaGg07wGocBTeijgzHPVfTRYibMxqUmPg= 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 10:40 PM, David Hildenbrand wrote: > On 10.01.23 04:57, Yin, Fengwei wrote: >> >> >> 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, > > 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. > > Right, PTE-mapping higher-order pages, in a faultaround fashion. But for pagecache etc. that doesn't require mcpage IMHO. I think it's the natural evolution of folios that Willy envisioned at some point. Agree. > >> >>> >>> 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. > > But it exists :) Yes. There is extra memory consumption even it's 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. > > Thinking again, we might want to piggy-back on the THP machinery/config knobs completely, hmm. After all, it's a similar concept to a THP (once we properly handle folios), just that we are not able to PMD-map the folio because it is too small. > > Some applications that trigger MADV_NOHUGEPAGE don't want to get more pages populated than actually accessed. userfaultfd users come to mind, where we might not even have the guaranteed to see a UFFD registration before enabling MADV_NOHUGEPAGE and filling out some pages ... if we'd populate too many PTEs, we could miss uffd faults later ... This is good point. > >> >>> >>> >>> (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. > > I think for an upstream version we really want to avoid these splits. OK. > >>>> >>>> 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. > > Yes. And the whole concept is abstracted away: it's logically a single, larger PTE, and we can only map/unmap in that PTE granularity. David, thanks a lot for the comments. Regards Yin, Fengwei >