From patchwork Mon May 20 16:56:36 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yang Shi X-Patchwork-Id: 13668485 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3E10CC04FFE for ; Mon, 20 May 2024 16:57:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:Subject:Cc :To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=NUtwcS7d5oySWsiaEkDRuEOngWnmNXq+u51YJLnB4a0=; b=W8vSWsjwvRmBTr muSmbs3FwGkO+3fgTCHdNygC85UKcExQTS/7B7REtu3x53WA8OrelFn+lAeMfgd/6M/XcWvOMfvYX 88d8s/Xu40fHkkJbmCB2VHTr3r+HbrGf2Zdb/DAQc/n4pQEsOR31txfuI/oYotrLJM5gRdAhbxa3E Ub13ywo9oekk9Yu4uqSQEYmFBa2rK+JO/nCX9wBXdyv0QQewCsav4dslOQ3wjRwM/fgVUYI+O7cF9 YHeXmmrawQBExVobFhmi0ro5M7KQPJFA5trnXl713P4PLJylOKI4pXROwwJ6ra4hcwn5etupWGgaf I+jCUBga/3fP0KF7JnCg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s96Jw-0000000F3x1-2OpP; Mon, 20 May 2024 16:57:08 +0000 Received: from mail-dm6nam11on20700.outbound.protection.outlook.com ([2a01:111:f403:2415::700] helo=NAM11-DM6-obe.outbound.protection.outlook.com) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1s96Ju-0000000F3vr-0N2z for linux-arm-kernel@lists.infradead.org; Mon, 20 May 2024 16:57:07 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PkWMMxy3WTh1seB3MG+p6ZaLPIgfKT7inpmZ/dd5Pg/Ht43aWynK6ahvbqlHLrxbt82rbEzZuYQVLEucPKsrFp+I8LuiT1dD9IARKlVb50be8U9CR1iB6vqSFhNIpemG4djnQWbgYz1EKB3B99hdOOXiONDLhppLyxhtk+oOO2xhdaFVHs7Js8l8s6Z98//DPbpZ5Vh7SlpqlcCSvECD48TKtvQwS/RGWOroUZCbxuYaWfHT9N1D68Q6F6Mc229Zo3m0MU89qgrJhm7442W7jYGBtDALVX4VI+37t5HnxmGtjt8SWv1Mx8/M18kAEbobjAwnJJlb51lClcN3iWcncQ== 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=n+Viu1N/haBIm9yQB84t2VpMMxz37y9cbV7/gCu0vjY=; b=Ozi8dmjZFy8p9fDdxpRjgOqnOUP70X9gYQ8C0PAxJcPwicr80udcxZxVsa8AxsU906VC/QiXzIdnMgwtGAW2PCv7FmtQVFNDzQt/MzqaCo8UNJjOz5u5ZXmpmishBfYyx2CAhtKOYyiH7cXdY/VgrRcP+o3w4X7eDihMnByZLbgB9bLHYE7TeMO3BncsvYnd8ZHyIy4+d+tQyC81UOTdVqCYzaVsBMIJRFjd7+jAWHMvteOP3LjXFt/XQrHpoLuSZjBCtFvu21YANNvjohwgXaivrpwxxKjZQFmiNdioH+PjERVULoxNT+GncMkvoG/MZ7NranLFpgHKsIzQmUy92g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=os.amperecomputing.com; dmarc=pass action=none header.from=os.amperecomputing.com; dkim=pass header.d=os.amperecomputing.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=os.amperecomputing.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=n+Viu1N/haBIm9yQB84t2VpMMxz37y9cbV7/gCu0vjY=; b=rMvlXGstLSeaBrGIAiFKvWhVx+tUs6/I4MIapZRi8Fw6pEuldpW4+DWucUoiOdKlNtOCCS6z7q9oFa5IUzaTDIFwrX0RqCoMoiCkEdHAJ2ePwFymM2AqkHBaHqdhM61HTdrOX85nwWmiPrVpsUBR9YkAAWly95Dnwtt4pj3/5xc= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=os.amperecomputing.com; Received: from BYAPR01MB5463.prod.exchangelabs.com (2603:10b6:a03:11b::20) by SJ2PR01MB8008.prod.exchangelabs.com (2603:10b6:a03:4cb::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7587.36; Mon, 20 May 2024 16:56:54 +0000 Received: from BYAPR01MB5463.prod.exchangelabs.com ([fe80::4984:7039:100:6955]) by BYAPR01MB5463.prod.exchangelabs.com ([fe80::4984:7039:100:6955%4]) with mapi id 15.20.7587.030; Mon, 20 May 2024 16:56:54 +0000 From: Yang Shi To: catalin.marinas@arm.com, will@kernel.org, anshuman.khandual@arm.com, scott@os.amperecomputing.com, cl@gentwo.org Cc: yang@os.amperecomputing.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [v2 PATCH] arm64: mm: force write fault for atomic RMW instructions Date: Mon, 20 May 2024 09:56:36 -0700 Message-ID: <20240520165636.802268-1-yang@os.amperecomputing.com> X-Mailer: git-send-email 2.41.0 X-ClientProxiedBy: CH2PR18CA0011.namprd18.prod.outlook.com (2603:10b6:610:4f::21) To BYAPR01MB5463.prod.exchangelabs.com (2603:10b6:a03:11b::20) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BYAPR01MB5463:EE_|SJ2PR01MB8008:EE_ X-MS-Office365-Filtering-Correlation-Id: 525e9039-e274-45b2-eec5-08dc78edda0b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230031|366007|1800799015|52116005|376005|38350700005; X-Microsoft-Antispam-Message-Info: AGzNzw1nV8tJNQjK3LLKL2NnG7dwd4IcO9FGdlOnasSizjtNNDoHY/JMBNsNho4EsKMBRLmz/Ut0GFO12ffRVv+SZrGCGqLS9rLd1ijpKk1HapCfBAfUFqTdKr7OCnZhPXTBGnGjNHvz+BgRiay6jFTOrndVd/Bkvc+Y008Czk0usArMS1nt/9IFJzitZX1u8TKg+oeV+BB09KKi5DvjzqHhmAD+zJB82sSfpPYxdMgupSH6/7GoVQGxkrJnT9kcD27e5nifK0iuY7SNzYc9irX5zaSwb8/MrzElZrXpgPa0MYzBMOIO2yy3KtGEs+l9P+fEtdYNcvoZJdh5gSfAdV5xjAWkECOb9r0uh1vrN7vKmSK+0Kq71fVxc6GXd6cAjy6hwR99KCsuIN72jl0qNlz8MXmyZlk9diVdkxYMsVw1PiVUN4tkFV+KGDbXSN1v4XjjeF8yp6F0HYrTNzJPVZ+/VkEiCfetGmtBjitcufNxIsrbD6wld3jvstBWcoi/x+swAFeiRx+JIULfRQdnQUd9o3LylHO9jN2qa5Jim+vDBDQHs3pr4Xbb8au23GENm9P9uhSrW3J19VVOC/MisD5mzLmKYKbpJu9NipCJfTxwQjQQq2yyk6WGkCOOeEmUb8PiGXsyys4Ax3lxI0fWKU1f9pyx5JhA5ZNeIZvo7Bi5Vehz1N4OVmX799wDAPx+MuemC+E8fdUDlzynuzk+fBT7B3Ijb5Gwlghyc3e62H5p6/GvIO33pSdDdNyLZ2vLQqIKcetMr/CxWkXvBngRr7cQo0NzQRU3V6T0POzJMUoOKBw9zsuXjTIab196elIrBejsCLn9QKK1gx0Yk1nq7Y+y8jqADXnxBRUFZ/50c2slyw4iyk+CT6qVrZHa2RgUVmiuM5luhHf0pyqXCozx3AUgC1Td1cHRD8ypYdGtB+XsKxoiTaukZTGoSv7Sp45IVDX/A96nuElO74SU4NedLmN9zyXyQ5Hbf3wJN3A7Np/AtGD5EclUqkW/ZOrgzYwx5uAM3KZ8/VwG8cSUjddPm7nyHZysoqbDuCykvdXR0ttgAhac9Wg3/dk+7MsUfwCmezoSProjteSRhPxVfsC+CHHhRMAYndu/lo0NGeC2hJaLkGtL4TszemUYENZSjW9bjAFs2capR5XLSHzX588LixAydn6ipA6SSzVdm7gKsmESHT7vL/jg/9dCBVCHZzKL0g9VzuwSxSgY4r/LygFS3AIPbcWCs4SHtlz65IkSKFcap3u6cJCiBRU5CozGwH+njauql3hfnqmx6pUBdsxwrpgk7Gp0L8B5M13kGbUoO+EEtboaV1x9Q1AJOMRMCUia5VzD0OB9fwZ13tAEgBYi8Q== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BYAPR01MB5463.prod.exchangelabs.com;PTR:;CAT:NONE;SFS:(13230031)(366007)(1800799015)(52116005)(376005)(38350700005);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: oJw3SgbBZGiGSw4aj2kbo8zKjCRY5wbDqQrHPS1gZjKefS0nmc5njppz7mn8RhxrK2A1FdgE0Wx6mvn6CziqEW4LFujR9Ccr32BA2oQP2ARMRHj5u3/FUu5+/MxInA48BuL7NwG0WQ0GeM9qERU96ACI/6rHrHE9WG4MoQWbNM8fWJ6aahflR2ybMdRKLI2AvCAVIAGgRJx6RWehk7GFOZ4i8eQNQi95fJ9nlr9hlQqqL4cl3cRym0HlLD9FycXAredQ19Wy5rIZ1KQrYWfNHpHgjDbKZIAtwvweTtr3GstiR81uX9tTMgY0sx8X2JPQLzy4DXTuuqybrtO5UeX5d4KtxfRXs6CC+rhMVkZfxg/rLz3de9BSHHQN9qwxpp/7ZhBkq0ozGa0JneRqCYMrEWGg6KWaViJUBs0c0BtsSJbNEOIZfCYk54hc8d8KzpcMZB4EPbMO9CXrCpFHgoRB0IO5i+0UQX6F3alAFSKggMOofubh6a49gr5Tcy1wZmUSHGZdQk+RRTNV6toqz27gCzC4uO+roc70Gmj1A/Ztsm0LXusHkgtA1mA4RZSw4jnnbGjm/SzCwXdl2j5/YsJN4IW/c9cEEnTALyy0iWVI3H9tZ8yJrFmT59t6BgNq/HS1KTncq6UCxFbfw+/iAG9ixyHeV1Jopb2edwuLIVBY5AiCxn/lRa1h8o0bfCcNH8m9R3q/7VnO+kThzgLMrZ3wJ8KReEoQRUWZNeFPVmncVcl/ilOta2s/yRCcga2Xvb8ZZ/P4YCI0R2QMn+gDnsGmk5PZV477Qnb3rg5IMoQzXBddmLZfBE2XuC4iQLKPHdYDBxJHtTRkkrRK6Mm/e8s7ltsgK/YUA5N12jOiuy0oKuoVumfd56Qyv/Qr5jfStri6FLc8g2NGAZWpsCh5NNjigbP0dol/Ow8C906ZiBv5GuGlP/jCTavqDzzXorl8txIpyvnFMwyIZIuey+aZdxy5XB+uM7OOvnqlTRtL4BPUWWxkkm+haWQwhIH8NsVmIn2QOSvPv/bPn2E3IwaXRcAjCJ8TcD9GGSwuHHemQssJOZbjeqshPI1o3PxD6cbweg8VLvdL8HUmVPD3ygTK7v9lCogXPzZBxqVBHvXWQOMCsLgcwBivX/XThyOhPy8pFJE60iuBs0f/e26j1Gd5wz15IGb5MeXHSIYtfMSp6Yebq+HIjVQPaHJhad08ykUGKlk1v86U7Z2Kcx6cTCAwPypxj+6sm684lGRytEaM/z3lXP23ZHqw8mEF+Yr6gkcmjP9c1ohiTj5F/HyLVJAQRwvgO3HvNc8Wvw1pNhJek5XBHfkyVWscGuKywHKUrHfxYhSJufGx2pIrIkgJrfvBeQxXGqEpb5Ri7c21b0dng5NdchRh6tSuH+IMUrUd8MA0cVCgNXusS3YcpncTXfqZk9LpjyJhT3mgwPSOqhcKyIZo4l18ZrX3aNrIntBy88koDMwhJF4am7DEHmQG0bpXpCLWnAEdBdDliX5SIqYEgjJaYCg02Q2P9efKGTvI83gkrgojXnOu8CiT1XGZYa45ZniNAZqNQ6JHLEQJfr8KrXljJkOckoDpzvxXU5ufQooxF2iorjt0rbONHIulDf/OL4230yymO7I3I4sLkaWkIxnuZPU= X-OriginatorOrg: os.amperecomputing.com X-MS-Exchange-CrossTenant-Network-Message-Id: 525e9039-e274-45b2-eec5-08dc78edda0b X-MS-Exchange-CrossTenant-AuthSource: BYAPR01MB5463.prod.exchangelabs.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 May 2024 16:56:54.2659 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3bc2b170-fd94-476d-b0ce-4229bdc904a7 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Eo0ub764BuEpAYw9+cZUuFlZ+dZl2WSlammiTuyejCpPQ8fYUV1WwpMLCBMrvZ6RkBsJr85b6skfVZZTK6igiPqSUzg+MIqVS/VUzZTVOGs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR01MB8008 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240520_095706_288261_91894CD5 X-CRM114-Status: GOOD ( 20.43 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org The atomic RMW instructions, for example, ldadd, actually does load + add + store in one instruction, it will trigger two page faults per the ARM64 architecture spec, the first fault is a read fault, the second fault is a write fault. Some applications use atomic RMW instructions to populate memory, for example, openjdk uses atomic-add-0 to do pretouch (populate heap memory at launch time) between v18 and v22 in order to permit use of memory concurrently with pretouch. But the double page fault has some problems: 1. Noticeable TLB overhead. The kernel actually installs zero page with readonly PTE for the read fault. The write fault will trigger a write-protection fault (CoW). The CoW will allocate a new page and make the PTE point to the new page, this needs TLB invalidations. The tlb invalidation and the mandatory memory barriers may incur significant overhead, particularly on the machines with many cores. 2. Break up huge pages. If THP is on the read fault will install huge zero pages. The later CoW will break up the huge page and allocate base pages instead of huge page. The applications have to rely on khugepaged (kernel thread) to collapse huge pages asynchronously. This also incurs noticeable performance penalty. 3. 512x page faults with huge page. Due to #2, the applications have to have page faults for every 4K area for the write, this makes the speed up by using huge page actually gone. So it sounds pointless to have two page faults since we know the memory will be definitely written very soon. Forcing write fault for atomic RMW instruction makes some sense and it can solve the aforementioned problems: Firstly, it just allocates zero'ed page, no tlb invalidation and memory barriers anymore. Secondly, it can populate writable huge pages in the first place and don't break them up. Just one page fault is needed for 2M area instrad of 512 faults and also save cpu time by not using khugepaged. A simple micro benchmark which populates 1G memory shows the number of page faults is reduced by half and the time spent by system is reduced by 60% on a VM running on Ampere Altra platform. And the benchmark for anonymous read fault on 1G memory, file read fault on 1G file (cold page cache and warm page cache) don't show noticeable regression. Some other architectures also have code inspection in page fault path, for example, SPARC and x86. Signed-off-by: Yang Shi --- arch/arm64/include/asm/insn.h | 8 ++++++++ arch/arm64/mm/fault.c | 38 +++++++++++++++++++++++++++++++++++ 2 files changed, 46 insertions(+) v2: 1. Made commit log more precise per Anshuman and Catalin 2. Made pagefault_disable/enable window narrower per Anshuman 3. Covered CAS and CASP variants per Catalin 4. Put instruction fetching and decoding into a helper function and take into account endianess per Catalin 5. Don't fetch and decode insn for 32 bit mode (compat) per Catalin 6. More performance tests and exec-only test per Anshuman and Catalin diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h index db1aeacd4cd9..1cc73664fc55 100644 --- a/arch/arm64/include/asm/insn.h +++ b/arch/arm64/include/asm/insn.h @@ -319,6 +319,7 @@ static __always_inline u32 aarch64_insn_get_##abbr##_value(void) \ * "-" means "don't care" */ __AARCH64_INSN_FUNCS(class_branch_sys, 0x1c000000, 0x14000000) +__AARCH64_INSN_FUNCS(class_atomic, 0x3b200c00, 0x38200000) __AARCH64_INSN_FUNCS(adr, 0x9F000000, 0x10000000) __AARCH64_INSN_FUNCS(adrp, 0x9F000000, 0x90000000) @@ -339,6 +340,7 @@ __AARCH64_INSN_FUNCS(ldeor, 0x3F20FC00, 0x38202000) __AARCH64_INSN_FUNCS(ldset, 0x3F20FC00, 0x38203000) __AARCH64_INSN_FUNCS(swp, 0x3F20FC00, 0x38208000) __AARCH64_INSN_FUNCS(cas, 0x3FA07C00, 0x08A07C00) +__AARCH64_INSN_FUNCS(casp, 0xBFA07C00, 0x08207C00) __AARCH64_INSN_FUNCS(ldr_reg, 0x3FE0EC00, 0x38606800) __AARCH64_INSN_FUNCS(signed_ldr_reg, 0X3FE0FC00, 0x38A0E800) __AARCH64_INSN_FUNCS(ldr_imm, 0x3FC00000, 0x39400000) @@ -543,6 +545,12 @@ static __always_inline bool aarch64_insn_uses_literal(u32 insn) aarch64_insn_is_prfm_lit(insn); } +static __always_inline bool aarch64_insn_is_class_cas(u32 insn) +{ + return aarch64_insn_is_cas(insn) || + aarch64_insn_is_casp(insn); +} + enum aarch64_insn_encoding_class aarch64_get_insn_class(u32 insn); u64 aarch64_insn_decode_immediate(enum aarch64_insn_imm_type type, u32 insn); u32 aarch64_insn_encode_immediate(enum aarch64_insn_imm_type type, diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c index 8251e2fea9c7..73f954fcb8c7 100644 --- a/arch/arm64/mm/fault.c +++ b/arch/arm64/mm/fault.c @@ -519,6 +519,30 @@ static bool is_write_abort(unsigned long esr) return (esr & ESR_ELx_WNR) && !(esr & ESR_ELx_CM); } +static bool is_el0_atomic_instr(struct pt_regs *regs) +{ + u32 insn; + __le32 insn_le; + unsigned long pc = instruction_pointer(regs); + + if (!user_mode(regs) || compat_user_mode(regs)) + return false; + + pagefault_disable(); + if (get_user(insn_le, (__le32 __user *)pc)) { + pagefault_enable(); + return false; + } + pagefault_enable(); + + insn = le32_to_cpu(insn_le); + if (aarch64_insn_is_class_atomic(insn) || + aarch64_insn_is_class_cas(insn)) + return true; + + return false; +} + static int __kprobes do_page_fault(unsigned long far, unsigned long esr, struct pt_regs *regs) { @@ -529,6 +553,7 @@ static int __kprobes do_page_fault(unsigned long far, unsigned long esr, unsigned int mm_flags = FAULT_FLAG_DEFAULT; unsigned long addr = untagged_addr(far); struct vm_area_struct *vma; + bool force_write = false; if (kprobe_page_fault(regs, esr)) return 0; @@ -557,6 +582,11 @@ static int __kprobes do_page_fault(unsigned long far, unsigned long esr, /* It was write fault */ vm_flags = VM_WRITE; mm_flags |= FAULT_FLAG_WRITE; + } else if (is_el0_atomic_instr(regs)) { + /* Force write fault */ + vm_flags = VM_WRITE; + mm_flags |= FAULT_FLAG_WRITE; + force_write = true; } else { /* It was read fault */ vm_flags = VM_READ; @@ -586,6 +616,14 @@ static int __kprobes do_page_fault(unsigned long far, unsigned long esr, if (!vma) goto lock_mmap; + /* vma flags don't allow write, undo force write */ + if (force_write && !(vma->vm_flags & VM_WRITE)) { + vm_flags |= VM_READ; + if (!alternative_has_cap_unlikely(ARM64_HAS_EPAN)) + vm_flags |= VM_EXEC; + mm_flags &= ~FAULT_FLAG_WRITE; + } + if (!(vma->vm_flags & vm_flags)) { vma_end_read(vma); goto lock_mmap;