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 76CDCC36010 for ; Fri, 11 Apr 2025 09:21:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 879EC2801A8; Fri, 11 Apr 2025 05:21:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 825B828019B; Fri, 11 Apr 2025 05:21:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6C71D2801A8; Fri, 11 Apr 2025 05:21:46 -0400 (EDT) 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 4E13628019B for ; Fri, 11 Apr 2025 05:21:46 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 53F2FBCD60 for ; Fri, 11 Apr 2025 09:21:47 +0000 (UTC) X-FDA: 83321220654.03.2D4E2C5 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf23.hostedemail.com (Postfix) with ESMTP id 8FC70140002 for ; Fri, 11 Apr 2025 09:21:45 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=SjXHwmnM; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf23.hostedemail.com: domain of mingo@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=mingo@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744363305; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ZteLwuA1bmLYzwnL2LaYDuIzt8I84fe5eenU5nTxc/4=; b=sR4Qi4x0VorBBnBflklQ6M2RHPUTku6W+k6Rk+x2C65tuh7M+8g2e0qWr6hn2Uw9XBpiUq 3NKrZ3LOxVDdmXbo3Bzn9LQVfHEgJuBc4ReRR1/x6j9OAlarOmjv5WF8QDMzkWaKVsEhJY rlYlLT6dOAJCNZg08wT3ne6SxzikmwU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744363305; a=rsa-sha256; cv=none; b=I44zDHxPqxq3UQydUkurVLMX9T1jDww6HNGSpvtCjJvZspJ6bhV4ORwWhI+FgV47G/s26C UdoCPTZXZcwUEsWHKhk0gxxF0YMMEcpSCRdlXJDKLRVc/xVKAULwayjc7gYZLsTzAn7Obw juk2NMtXR6k+bOjvEOGnzo92aYZc1uM= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=SjXHwmnM; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf23.hostedemail.com: domain of mingo@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=mingo@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 88E5D44F30; Fri, 11 Apr 2025 09:21:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 61A46C4CEE2; Fri, 11 Apr 2025 09:21:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1744363304; bh=TU38Yz0wslbhAhgiT67MgDKR2lBijTLSXefhthfuYAI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=SjXHwmnMOpa/T9EDIGZIX3IDPYF02ahzYO+YFFts9WBT9LzVU+sYE7lMFunEOQ6jC i3wle5PIGi0XEF7KoFSrobsHG4iLPceRLhg3C6GU3Ry3UNp7hkKNQcQYQ/s4/NLn+3 Q0EFYQ0FW4/p5igzjZmcqVsIOYDmArkMmLPPFLrgyi5FToLl/MbdIPVJjn76QEOMPC i53dzsttNM1if0JeK0UXoTKlynDInlA6vtJAPClKBzRETPL9clMN33KrpH1gQo6+bh 5/FPJTOH4S0Pe27UzE9YpsNYeyXYnrbnG+Ca6jrZMF65hsEqwfCPUL/tiO65R1C7rW ATb6+H13FBf2A== Date: Fri, 11 Apr 2025 11:21:30 +0200 From: Ingo Molnar To: Kevin Brodsky Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Mark Brown , Catalin Marinas , Dave Hansen , David Hildenbrand , Ira Weiny , Jann Horn , Jeff Xu , Joey Gouly , Kees Cook , Linus Walleij , Andy Lutomirski , Marc Zyngier , Peter Zijlstra , Pierre Langlois , Quentin Perret , Rick Edgecombe , "Mike Rapoport (IBM)" , Ryan Roberts , Thomas Gleixner , Will Deacon , Matthew Wilcox , Qi Zheng , linux-arm-kernel@lists.infradead.org, x86@kernel.org Subject: Re: [RFC PATCH v4 00/18] pkeys-based page table hardening Message-ID: References: <20250411091631.954228-1-kevin.brodsky@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250411091631.954228-1-kevin.brodsky@arm.com> X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 8FC70140002 X-Stat-Signature: jjaf31armm85a3fmxpj8xpfwqoxmtue6 X-Rspam-User: X-HE-Tag: 1744363305-713947 X-HE-Meta: U2FsdGVkX19LL4NFjs9+sj1JPnziArhz2SaAer3B0i/4+gskUQvPa1dqs6iQ7PGlZWVUtORw9ByG4v3tDmzRTv+xTk5fl6On115HHxa3DfgCaQaWM5TuA0bz9HqKOndKiTs/8RLANyB/ju9GyX5NN+0J6Mfgxuldfb3zGZzvX/lKHIOJZyd8s4EzR/U9h20OHwzM3zCz064C8M23Js+/I4meM+bsdYQvLzOT9YIOQiOG22Feh3PscRBpi6Zhph9mxtLZFG8Z2ZkEGTUQu4fAdrifJaUdzQfaK5eoG84GoiUaF7l7q9Td7I/egmLzRhTmXYEpbJNPSwBmq7SMtpepPhf+8fqkD4ZQafNxnzhKuNkiogaJPLp8IVY/HtgUOnEx9ewPVgIhj4a76HZk3gfVV1b2/VBjxT5WqkW2zvEJeDGNW7IN9kNrhVTQehYPwea4GUlxhgA+IcLr4lvKYb48GBMiWRGNPDZCDmKmuBoOBcXibTTI2uZBkvZTLXPd7WXSRliQVELVPjlc1oITnJsDoyZHfktx10irTra09nOQOtq3MsOaaDswtJ054ueohExlGxdzIE+uJcjoSJmtJXknEDJoOn+y2CrLZ8gJAHO/21a3hCDxZku60ENhf4pg8PIsBnfTcf0eL/jJpSazj9yaoNBtzZFdW9JYhI81cjYbCFdBGOsYZiaR1AdjqIv/Y8CZhbGkBsqMWw5OvHA7FCeps0y89MuBb2ace0wUy9Y11I1WUhrIN+abCXji5QU1Ga1eH9XDa0afBD5Yf83YRhNEr1MkLza58wCUu2B84vRqPN8M1mFf4KDPDj2641vsvfGRbc+o9CFW2AfhZIVBOFCS4A7XGTMU+pBNmLDGVdQaId7d+eNBAh/vLiMYYhBdy5Uhq0htypWQIqmnEvEtdA8Y/dmEhVIvWxgkVb7ADzyhl7FBe7s2shO8TapOhCJQygbScJISl4r2vYcdix1y5fU F7Ol22+I UgKyucm4vTyCuXdNuqmoaMVj21gOUAjHgxc4QJCYP8KO1eFsM+ngAdbZAkVA8M2fsXACLE6/L9z2Ld7D6v5e1iDZdXiM/C8LQGYY5mYkup632V/UYZHR2ldEHggbZ7UiRcLgbdv8xEG7X12AzQW6N2Q/l3hOBpJAz4ruhtYcspJpo3dwuR/hND7O5QTvYUxD9ixogXmm7hlIYEMsCeATsQZ/i3Zc6Aaf1L9h+7RPtgwbvyZgMDVmIhhoOwAk1a2qZg2+2xSFm0+6TUtL1uHDgxASDcA== 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: List-Subscribe: List-Unsubscribe: * Kevin Brodsky wrote: > Performance > =========== > > Caveat: these numbers should be seen as a lower bound for the overhead > of a real POE-based protection. The hardware checks added by POE are > however not expected to incur significant extra overhead. > > +-------------------+----------------------------------+------------------+---------------+ > | Benchmark | Result Class | Without batching | With batching | > +===================+==================================+==================+===============+ > | mmtests/kernbench | elsp-64 | 0.20% | 0.20% | > | | syst-64 | 1.62% | 0.63% | > | | user-64 | -0.04% | 0.05% | > +-------------------+----------------------------------+------------------+---------------+ > | micromm/fork | fork: p:1 | (R) 225.56% | -0.07% | > | | fork: p:512 | (R) 254.32% | 0.73% | > +-------------------+----------------------------------+------------------+---------------+ > | micromm/munmap | munmap: p:1 | (R) 24.49% | 4.29% | > | | munmap: p:512 | (R) 161.47% | (R) 6.06% | > +-------------------+----------------------------------+------------------+---------------+ > | micromm/vmalloc | fix_size_alloc_test: p:1, h:0 | (R) 14.80% | (R) 11.85% | > | | fix_size_alloc_test: p:4, h:0 | (R) 38.42% | (R) 10.47% | > | | fix_size_alloc_test: p:16, h:0 | (R) 64.74% | (R) 6.41% | > | | fix_size_alloc_test: p:64, h:0 | (R) 79.98% | (R) 3.24% | > | | fix_size_alloc_test: p:256, h:0 | (R) 85.46% | (R) 2.77% | > | | fix_size_alloc_test: p:16, h:1 | (R) 47.89% | 3.10% | > | | fix_size_alloc_test: p:64, h:1 | (R) 62.43% | 3.36% | > | | fix_size_alloc_test: p:256, h:1 | (R) 64.30% | (R) 2.68% | > | | random_size_alloc_test: p:1, h:0 | (R) 74.94% | (R) 3.13% | > | | vm_map_ram_test: p:1, h:0 | (R) 30.53% | (R) 26.20% | > +-------------------+----------------------------------+------------------+---------------+ So I had to look 3 times to figure out what the numbers mean: they are the extra overhead from this hardening feature, measured in system time percentage, right? So "4.29%" means there's a 4.29% slowdown on that particular workload when the feature is enabled. Maybe add an explanation to the next iteration? :-) Thanks, Ingo