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 C27C1C48BF6 for ; Mon, 4 Mar 2024 16:45:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 155C06B007B; Mon, 4 Mar 2024 11:45:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 108556B007D; Mon, 4 Mar 2024 11:45:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E9ADC6B007E; Mon, 4 Mar 2024 11:45:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id D40EC6B007B for ; Mon, 4 Mar 2024 11:45:12 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 9DAAE1C0D00 for ; Mon, 4 Mar 2024 16:45:12 +0000 (UTC) X-FDA: 81859931664.24.34551C6 Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by imf18.hostedemail.com (Postfix) with ESMTP id 277AC1C0010 for ; Mon, 4 Mar 2024 16:45:08 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b=fNwgbCyJ; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b="yrHEnA/i"; dmarc=pass (policy=none) header.from=oracle.com; arc=pass ("microsoft.com:s=arcselector9901:i=1"); spf=pass (imf18.hostedemail.com: domain of khalid.aziz@oracle.com designates 205.220.177.32 as permitted sender) smtp.mailfrom=khalid.aziz@oracle.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709570709; 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=DihVLM5aflOD12UTNLJFSDEBk+E38RSRwZz9RnGn1ZY=; b=gp1QscJIRob6jrzwv2FKCpCjf2l1+qOKUWVZWXriWMyj8B7BcNNenkyjfs3uP2/tX1MqMS p6MKAg3JxKUJ2vjCcwm6C4dWpvzbzxQbzoKrLdly98Q7mFUOtAXArcuiwPl1K0EUj+XndG WAaq5AJN1BwYCsLowgn7VxBFKkQZ3uM= ARC-Authentication-Results: i=2; imf18.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b=fNwgbCyJ; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b="yrHEnA/i"; dmarc=pass (policy=none) header.from=oracle.com; arc=pass ("microsoft.com:s=arcselector9901:i=1"); spf=pass (imf18.hostedemail.com: domain of khalid.aziz@oracle.com designates 205.220.177.32 as permitted sender) smtp.mailfrom=khalid.aziz@oracle.com ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1709570709; a=rsa-sha256; cv=pass; b=AeeHyUDma7gOgMbHBr8RlDSJgRgQT7+HKldPuq4nxoeeQ1gQjo6rpQS54BNvxv/UPCIYzE zLrSKx9LVl3tDiqXTdjFYrBhj8aNC7JmS4dHVUy+KfFf885UCgVS2ijZCKInmUt4YZJNzL 0ANF/rWCWVBkPnvAg32vboiwyFP2U3Y= Received: from pps.filterd (m0246632.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 424GXwqN030992; Mon, 4 Mar 2024 16:45:08 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=message-id : date : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2023-11-20; bh=DihVLM5aflOD12UTNLJFSDEBk+E38RSRwZz9RnGn1ZY=; b=fNwgbCyJ8+wbZS+VY0bSL7Rl+MuKIPf7DmiSOQy7+Ku6KUqkFowBNxzEOS8vh7hV8hiG 1pAfi8MiyyvPjPSWSFDJjulfc7sFoE0E4Vhf3AvjV0KbjqS/TbnuvGaoLcYHwEz60rYq bSZNfx8/ucxhrIdPF9QLBjmwDCyJldU7KJf6I9coXe7wb/6XSl/QXGvylsSlWOlZp6D9 RoNTUEyrfXZfPGKzFgtTAuUgBJPahRpksJExFW5m1xtyRvgo/Q9HMY+2UuurbV/T0RiV uR0KQNKqvQi2JYAwHtxbHMCsJEGVkEYak8zwZh5bCQMBDTU2EFHB5t42bWyBSJIBI0qM 9w== Received: from iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta03.appoci.oracle.com [130.35.103.27]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3wkuqvbw1g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 04 Mar 2024 16:45:07 +0000 Received: from pps.filterd (iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (8.17.1.19/8.17.1.19) with ESMTP id 424FY0FB017046; Mon, 4 Mar 2024 16:45:07 GMT Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2168.outbound.protection.outlook.com [104.47.55.168]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3wktj61svj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 04 Mar 2024 16:45:07 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ibbq/A/oIikU+/AWOT//QVdI0YNiijTKkZJLIfFjPfmcfteZnWYe8S6xYT90HKiffyT2Z5SHofsAG8iwzBIE2hHNbDg+U48zRtrn2bFnOLzk009etIcH9mjt5l18b6Je9xIrkqV7ZbKIgEL+uzX4TtYjvmojTUYyUJzyGH85OFb03b8vnooDXoBUAKFReU+mn9SFKsQnjP92iUIjccweyTcNciEspZDPAAqTAriWn5dI/7VuEJS9DBTodqTd1F/fEgG9BZGXQKFDqoD1CsIFe+cz3ya1X7jySKzAc3COPncUCh9zFpZzs4Z1wrgN2DFUrZUeVaGUbzw/zp86A7bKjw== 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=DihVLM5aflOD12UTNLJFSDEBk+E38RSRwZz9RnGn1ZY=; b=mbfW43sBOq5zHQO5Y9MnccSNcSsrPTEsdePtN2MpsYjvikZ1d0rFxtcoEAYIBKYbNFcnOQr9cvJUsrFrWmy1JK5sgecCPHiLPno9om8OPemWa0Tz04mqIbdKxlYheQ/+1tHp5kCrQYgHYJmVxYg9SdEpzPxZ5upirVOq0EmPRI2rwfkxfQ+wCh3zv/vKOpx+RdY/iaJ+V2e+lHxJW5FTnyns6Gm7CnHlBT+65du0SDxbMy/mk3ZZkcAFhl7aSbTX/hyS81UEJxpBkVANaHpHjv0UUnQa/7IKInp9rfmuIFkW8Wv/YxUoikrB2E/A61z+F+ObjF0j9XX7Gq9c3hj3Sg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DihVLM5aflOD12UTNLJFSDEBk+E38RSRwZz9RnGn1ZY=; b=yrHEnA/ilIsAZUjGMPuDPy38vFCVNpLm3N5Es5et3ikQMSsgCb06uWQmm3uOumQxPVeRqzwUgHxn3oh4p/0cJcizSCCI0Ho5F12lr7w/nNeVf7F5pRfvOjL0QRqSmyswquPbb0zgD0QAWXOtJ9CxPAlnDEjKhxXLbTp1/NfCpYg= Received: from CH3PR10MB6810.namprd10.prod.outlook.com (2603:10b6:610:140::15) by PH7PR10MB6457.namprd10.prod.outlook.com (2603:10b6:510:1ec::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.38; Mon, 4 Mar 2024 16:45:04 +0000 Received: from CH3PR10MB6810.namprd10.prod.outlook.com ([fe80::6dee:133a:425:1d3f]) by CH3PR10MB6810.namprd10.prod.outlook.com ([fe80::6dee:133a:425:1d3f%7]) with mapi id 15.20.7339.035; Mon, 4 Mar 2024 16:45:04 +0000 Message-ID: <83515478-f064-4d28-9125-748860e61a48@oracle.com> Date: Mon, 4 Mar 2024 09:45:02 -0700 User-Agent: Mozilla Thunderbird Subject: Re: [LSF/MM/BPF TOPIC] Sharing page tables across processes (mshare) To: David Hildenbrand , lsf-pc@lists.linux-foundation.org Cc: "linux-mm@kvack.org" References: Content-Language: en-US From: Khalid Aziz In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: SJ0PR05CA0184.namprd05.prod.outlook.com (2603:10b6:a03:330::9) To CH3PR10MB6810.namprd10.prod.outlook.com (2603:10b6:610:140::15) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH3PR10MB6810:EE_|PH7PR10MB6457:EE_ X-MS-Office365-Filtering-Correlation-Id: 4d48f4b0-eee4-426d-f773-08dc3c6a7139 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: LDlyrnDZfTsPXFsRAJtAuIpTZqY3Xnp3cxy9/WtZqvzRRgtBvOLsXC9zyLFWzQjih8MSh8ZMCbSK+sFPKHTJQ1iTprZVcx28xz41Bf2/dcRjVfFdfVkCdUrf0I94uT+edj+pcYtvp6pUSIRKuf2aLSQNIFVC6+NlbXksPmUNNld1GaKUvyUUkbuQxEZlP7yi2PPLeAUZo6Imyltqm/IEr47sX7SL6LJWZacUaQDW/IUlP6FeRYD2X3zT1BBSLRDtLofiLl3cq5/igL+XDuAGWTMz7MGP1q2fkgvRwCp2LoUlfhrtn/ixchmmqB0KZAHo7F7df/w8aORnCW4zqyfXAQLP4vHFVWzzYIH1y0+NKaCcKv8gc5DHNifZ+cxq9hXvVpQWjqXtxiIE190JsZuZ+52huaFqS/SVke20z78ngYrykobUQabMUT6rOxo5eOnYclh8SsgOXQxD/uJ74I8A/Z+iUPRVe0pV5ubjKXqXYWEmwup6k7EOrmWllqvXvmBf5XQR5PRHl0Tg/F5xWxcuHgjO+/oNNG96YqzINs/2D9ktIsN0x60nqmLRybLYSXXt7e2QI9ETCdPjY4ino8mL1byU4sMzCvOadQbeDZDEO7Y= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH3PR10MB6810.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(376005);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?L3VncCt3Y1B0NFFvaENKMlhjMHRkVC80cWVHejd3ZFVUR1ZKa3BRenFPVHRO?= =?utf-8?B?RFNWQmpwL01QQlNqVXVKUzJ4eUNRZ013V3pJc1EyUjVNbyszUVNNay9pUFZz?= =?utf-8?B?RmRJOVZCSlp6ajJSWW5nTE8rM0p2WGhGbWZNbkpzUXA2b3RqYUFrNm51cXVu?= =?utf-8?B?L2E1eXZYeC9mZnZJdjM5Z3hlVmxlM0hzZm1mZWdlSERaZUVSamxTbjAxeU1D?= =?utf-8?B?U1pYMTNtb2w4a0lQK2QxeEhHL3N4aHZlU3dSUFB0LzlwWjJsbUVqeTI4WGd2?= =?utf-8?B?aFpRV1lQcGdsVW5hWDNVNXplNkVQTWNxYmMwaXoyMVVRZkZjRW05MXdiSERC?= =?utf-8?B?WFJqYmJYS1pLSmt5aWNWZUxMWXJQM1l3dkZKU3A4MHNBTUZvTVBDMzdJM2du?= =?utf-8?B?T1liZ2o4b2xua1UwaEZVdEFMcVRyQ2FuV1B1ZC9EM3JpSCs0TUdRdUVxSzdQ?= =?utf-8?B?NDVSWDg0TWNQT2NXbFBQbkI4RnhySVhpTHNYVXpHZ2hXbXZDTjFVejBLRkZB?= =?utf-8?B?ZGpGeVZqaE8rWDEwcmQrR245UGh1c1lMK2VPR3lhdERnbURDZzRrS28xV0pL?= =?utf-8?B?cVVZbFNYaGpPSmREY25FbGtEMWp1U2RtR1VKL0hieTVRZGQvaFo3RWdBb2pC?= =?utf-8?B?OEZEc2kxVThjOVJRWmhZK2pqVlNHcWFDSjhlZjZ3QmZTdGNhRFE1ZXhreXM4?= =?utf-8?B?eE1CTExjMlhuMmh3ZmF1UUFZeHg4WmFCblJ1SXhBd2NuSC9JZllGS3ZLNVI4?= =?utf-8?B?aXF4TW9nMFFDMFRFbE4raWltSENZL0Z3dEN4L0Q2SWtnbXZtOEV4eVRHSHhK?= =?utf-8?B?VEdJWmxOMXJEUkxvNEM5TVE4b1BrRG85bGZtZGRXanZsbGE2VFN2cWlrbGUz?= =?utf-8?B?eFB0aFlFeG9UL3R0MVZpbk9Xb2tOTHNPZjNudmF4Z2ZsM21jV2FDN2dtcUIz?= =?utf-8?B?dlR6RnUyZlNMUE5VSWJCUHhTNEZVbC9WMlIvUkpWMVZaS2grWnJRMHhKTjhJ?= =?utf-8?B?MVhTMzNKTVMvRStLdkdxWmh1N0N6dFBJTjd0ZHY5a3FleVhCTi9nSzlrVVAw?= =?utf-8?B?QmIraTVPaHkxNnFLWVpoc3V2bFovNDhsN1Y1UGEwUFM4T0lCeVVxeXN3LzVC?= =?utf-8?B?UjRkWWtBV0R5STZqRGQweWdHeUdYclZSbTFXbEI4cHhNRjg4VzFZL0ZZdXh5?= =?utf-8?B?TUVscTltOERBcndDakM0Z2FJbVcyTkZUNHpNemJwTDRKN3g0TmNaaWY1UHJ4?= =?utf-8?B?S1JVT1c3RzJmazlYNU9zcDRzZHJzNEdhbDdzVzZhNUtnbHE5cEgrT0Z1SzJw?= =?utf-8?B?TU5YVERxSVVaaVkrNXNXcXZqK2xpZ2toaDBVZzVESVpQak9DUW5ZKzBZL25i?= =?utf-8?B?djJ6c1VjalJEdXBOY3FiaDhocWw4cGJWRStEVXJHbVdIbDJJb3VoUkdseDlt?= =?utf-8?B?TmZlSFVTY1pwMjdKRTEzbG9iWVRwTEFuQWF0blVFQTBpLytQUHlrOXRpMnNn?= =?utf-8?B?QjdQa2pKbGp2RysvbEx4V2hmSHNaWGYreEJJTmY2alphaEJ5dHJYcVZiN2xM?= =?utf-8?B?TkxrV1BXUUQ5ZW1wVDczbkduREZFc2JqbTJOa0w3S080YWFhOVJ4NDlJd08x?= =?utf-8?B?N01icmRPRTdqblJxTFdQTjkzckVoWnRvOUNUam44UkFuZ0R1NXhMaDAwUThj?= =?utf-8?B?cXlpTnNFVkFETFJlcThYb3NTcVM4WkdXcGtvV2Zna3orVExrUDlyR1JMZEpv?= =?utf-8?B?WENkaXhVU0MrbzBBV0laSmx4SUU5NjJsV3plUU41OGU5bkNlK3JIeEJaeW1Y?= =?utf-8?B?NVVETS8zSWFjMDFCOHR1MFpQSXJMeG9pZFBobzhLMGhmT2FOOFVIZlRkY2s3?= =?utf-8?B?dTE5YTVGdmhoek10Y2dxd1VtVkVtMlR2ZHRTWTREMmdGUjEyVGV2VENobmFz?= =?utf-8?B?Y29aQWlHbTNGWWVrOFJUVU4ySndPK0ZyajNwU2tyS3c2SkVXNkk0bzBWcHpQ?= =?utf-8?B?RWdsMDZzTFNKN0hxUlYvYURGQXY1cDdCM3pOTHF3emFVTDk1SjV4eW5BdE95?= =?utf-8?B?L1NnQm9hRWNvSFpGWTMwbmhqc2lma3BwVDFkR2ZlS0gyN2pkZ25GU2FMZDYy?= =?utf-8?Q?ZWLE7ddVSkT014znVNZDrfJnP?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: uTcicy5GRxfOPxqFDRyCcL7xcVy9dHGIeBnmgbblQD/cahskp9xzx07Wl6ldb9zSUYAF7mIoBex8wrq6h9WHMCfq6nDk+CHG1yaonAtVW71GloMZunQ3oJWYR467NrMycEamjHAs3HwkJCxE7cIKFyeHRggkdOuUjLSfaTg4rsJierjKnkca/ka6z+DYUrT93vXMOCCTdJLrLm5FovOSD82ltuboci9+EWgZ3N6Cr/Wxy9T4WVBbMloSSafZghz4gRt/vIlSMYwcNPRPIXJHgzwP8pbbPd46V29im3nQ1gi1HqbHNHDXIdEjSpUwDpzTf7+ZgqfozX9lT6aI4CDGpsUDYBtQ/CoHh7D07GTrpgbRkMbc9dO4fXt0QxDI4kTTCw6QJ9oLqMEXjwzrJ4RD43Pl9soS/ikstFmhC9vgAF033F3uid2+p5BQXmbx07n5NGNTj3Y92cDdkuaMfPx/LjE6gWpbNHloKit4Dw/6/PV4bewvecbDqoX8LQZ9rTLLIdHXx43X2gB7ylyKA95uKDZXEvUvYUQMLuSoevBpAb6XgEAnCy4/HYT1fM0jkC6VI0UnFVy79XQYUNEGOL5bRJTYwOVHJdqN9EXLKozFU1w= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4d48f4b0-eee4-426d-f773-08dc3c6a7139 X-MS-Exchange-CrossTenant-AuthSource: CH3PR10MB6810.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2024 16:45:04.5814 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: k8gkQ/FcDy36in2cqC8/2J3COeseP4EH6bP0Jiq6mEzuR18kwVE8+tLl6/JrELYvLQuF2E0WQCbkAeEpHJ7O+Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR10MB6457 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-03-04_12,2024-03-04_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 bulkscore=0 mlxscore=0 spamscore=0 phishscore=0 suspectscore=0 malwarescore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000 definitions=main-2403040128 X-Proofpoint-GUID: gBFSsjKDS24Uzs1XdzR0KOAMnF0Xc8YS X-Proofpoint-ORIG-GUID: gBFSsjKDS24Uzs1XdzR0KOAMnF0Xc8YS X-Rspamd-Queue-Id: 277AC1C0010 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: qt7ahp1k33snoku1hir1zqk9yj4gbfzr X-HE-Tag: 1709570708-661655 X-HE-Meta: U2FsdGVkX18mE4p/kkAQc3rPNKpTwq5OYuPSj/Hgfyv7E93lslr9Pl6j00/2y/Xub3rhuRJjhgSe9gotO5K3wmXTQN2blqQaB57FQlztMElC+MeRokOKLRRjzn/Ze72JxqWDgDNvyU4xlZblfR+4MF4EwPeh1FiICXpeCTrbO1ovFFb2PhccFvgdEjSYeJh4E2+MPNPDEANhxo/wNc2vXKr53GLUoGH3g15y6iQ88wTlgT9G3JtG/6oBwfEQLgX61OeUJbIxWZLSpaZYgFPc7GyQqGdAh9FvoxN0cc+QtI6T2l25Qmj+WBYsRHsGJWzRDutbxo8+tgEWVavuMHcb+akPK7zd7KpT4wd4nvVO0SxDnbaxLtXDCzH/WxJvrvWHWgwCHpxF0IxPwoinGWlitAT00yc42kETduugMPs5eyR0lPYzNukhWiNLOi+3nLOmQ4Uvz6tn5yCHKYoExXOw1uHadXIgiuVIzc2CCcPFi55/kWFPbghR71j7BWQMeZq6awmebkAJBkb8VjJGZgg4GtOBmvv53pMBcMIWGBWZY6yje0bepGk0QAzkCgs3VjfLkYtFZYKV12ubHtyWu1zC0yzfvIPznXveyoXkBDvuZpFJ42p9gzfc0brk5AbPAa7leMFCgMF26U8qEr96i0xMQu12RLckDsgpmNcYATZTqKV/aRrPy6ObxEpgoSx81UZPJOxSA84V26aWvFPFBvWpL8HH5dfIiXS5GjM2/NXwPVzCgaeG5cEUJKi7u7z9dwJ7685k5zFeZy2z4THJyBU8G8PnZfKUZ6ignvpBc/QMmja8hA7jPELz/cj/yttKkP/SuYb3i8BaukaE0T51BRgs6tiGBaRjloVkrVW4RN+iKmMg1SfbDEonCVlzp9faaLXC453AIByzI/Upnj1xoBh6UTnQTmPUKACu56tqHvrGPlAr1h/O10D4vBVdYVBgWNZ2YsShVMrkIaQnWixZbUO qfeN+xhR /07evWwD6rD0HmhdzO+r4d69FohNWlgCWPy3uJPtNe2TVEvB590KTD5yXDSDRGLD7YqaYiqq+n+jdYCBF5UFPlsMm9jVNuJzACYrakxmlumb9boqA5xgVOVXEcwYgkihv8jJHz8FnrLScOxhglCyDED6w51MCTjkHTbWHb+RC50DAKR01v9hhwXpUuK5KGW9gxY7H0eL58LkHKDoL8ICWNnbsNzbPshbvgoE0FEJ9CQ7fHxzgNMIJoDcKbLYMkparV8CVN8lqRpmHtRtfnS0/wmJWyF8bu/Ml37Bq0xI0Ul7KlIiHPM1l91Dtx6QwGv2x/v1CFiCy9l5I/JfyM9/bmXV5eMV5YLFmRHc0pGXFFujtaIefBrfxE+E5ZD7cePcWzRP0DdoQSlbu++bcHdQ9ZEueLKvcb863txi8WV7K3hviwvw0Ze96n7xMPrQylidZJNn9nd+dw3IsjiKDdf9OOXIxcVdN6idGLVixDfBVrnC8zkuQHu85XijffLoft9hw68vBURjam6gDFDu4oQtXqqCHWrQu7fuW9U+Gx2a0j8fVseEVBRvUoGP/7w== X-Bogosity: Ham, tests=bogofilter, spamicity=0.014364, 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 2/29/24 02:21, David Hildenbrand wrote: > On 28.02.24 23:56, Khalid Aziz wrote: >> Threads of a process share address space and page tables that allows for >> two key advantages: >> >> 1. Amount of memory required for PTEs to map physical pages stays low >> even when large number of threads share the same pages since PTEs are >> shared across threads. >> >> 2. Page protection attributes are shared across threads and a change >> of attributes applies immediately to every thread without any overhead >> of coordinating protection bit changes across threads. >> >> These advantages no longer apply when unrelated processes share pages. >> Large database applications can easily comprise of 1000s of processes >> that share 100s of GB of pages. In cases like this, amount of memory >> consumed by page tables can exceed the size of actual shared data. >> On a database server with 300GB SGA, a system crash was seen with >> out-of-memory condition when 1500+ clients tried to share this SGA even >> though the system had 512GB of memory. On this server, in the worst case >> scenario of all 1500 processes mapping every page from SGA would have >> required 878GB+ for just the PTEs. >> >> I have sent proposals and patches to solve this problem by adding a >> mechanism to the kernel for processes to use to opt into sharing >> page tables with other processes. We have had discussions on original >> proposal and subsequent refinements but we have not converged on a >> solution. As systems with multi-TB memory and in-memory databases >> are becoming more and more common, this is becoming a significant issue. >> An interactive discussion can help us reach a consensus on how to >> solve this. > > Hi, > > I was hoping for a follow-up to my previous comments from ~4 months ago [1], so one problem of "not converging" might be > "no follow-up discussion". > > Ideally, this session would not focus on mshare as previously discussed at LSF/MM, but take a step back and discuss > requirements and possible adjustments to the original concept to get something possibly cleaner. > > For example, I raised some ideas to not having to re-route mprotect()/mmap() calls. At least discussing somehwere why > they are all bad would be helpful ;) > > [1] https://lore.kernel.org/lkml/927b6339-ac5f-480c-9cdc-49c838cbef20@redhat.com/ > Hi David, That is fair. A face to face discussion can help resolve these more easily but I will attempt to address these here and maybe we can come to a better understanding of the requirements. I do want to focus on requirements and let that drive the implementation. On 11/2/23 14:25, David Hildenbrand wrote: > On 01.11.23 23:40, Khalid Aziz wrote: >> is slow and impacts database performance significantly. For each process to have to handle a fault/signal whenever page >> protection is changed impacts every process. By sharing same PTE across all processes, any page protection changes apply > > ... and everyone has to get the fault and mprotect() again, > > Which is one of the reasons why I said that mprotect() is simply the wrong tool to use here. > > You want to protect a pagecache page from write access, catch write access and handle it, to then allow write-access > again without successive fault->signal. Something similar is being done by filesystems already with the writenotify > infrastructure I believe. You just don't get a signal on write access, because it's all handled internally in the FS. > My understanding of requirement from database applications is they want to create a large shared memory region for 1000s of processes. This region can have file-backed pages or not. One of the processes can be the control process that serves as gatekeeper to various parts of this shared region. This process can open up write access to a part of shared region (which can span thousands of pages), populate/update data and then close down write access to this region. Any other process that tries to write to this region at this time can get a signal and choose to handle it or simply be killed. All the gatekeper process wants to do is close access to shared region at any time without having to coordinate that with 1000s of processes and let other processes deal with access having been closed. With this requirement, what database applications has found to be effective is to use mprotect() to apply protection to the part of shared region and then have it propagate across everyone attempting to access that region. Using currently available mechanism, that meant sending messages to every process to apply the same mprotect() bits to their own PTEs and honor gatekeeper request. With shared PTEs, opted into explicitly, protection bits for all processes change at the same time with no additional action required by 1000s of processes. That helps performance very significantly. The second big win here is in memory saved that would have been used by PTEs in all the processes. The memory saved this way literally takes a system from being completely infeasible to a system with room to spare (referring to the case I had described in my original mail where we needed more memory to store PTEs than installed on the system). >> instantly to all processes (there is the TLB shootdown issue but as discussed in the meeting, it can be handled). The >> mshare proposal implements the instant page protection change while bringing in benefits of shared page tables at the >> same time. So the two requirements of this feature are not separable. > > Right, and I think we should talk about the problem we are trying to solve and not a solution to the problem. Because > the current solution really requires sharing of page tables, which I absolutely don't like. > > It absolutely makes no sense to bring in mprotect and VMAs when wanting to catch all write accesses to a pagecache page. > And because we still decide to do so, we have to come up with ways of making page table sharing a user-visible feature > with weird VMA semantics. We are not trying to catch write access to pagecache page here. We simply want to prevent write access to a large multi-page memory region by all processes sharing it and do it instantly and efficiently by allowing gatekeeper to close the gates and call it done. Thanks, Khalid