From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "kevin.brodsky@arm.com" <kevin.brodsky@arm.com>,
"linux-hardening@vger.kernel.org"
<linux-hardening@vger.kernel.org>
Cc: "maz@kernel.org" <maz@kernel.org>,
"luto@kernel.org" <luto@kernel.org>,
"willy@infradead.org" <willy@infradead.org>,
"mbland@motorola.com" <mbland@motorola.com>,
"david@redhat.com" <david@redhat.com>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"rppt@kernel.org" <rppt@kernel.org>,
"joey.gouly@arm.com" <joey.gouly@arm.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
"Weiny, Ira" <ira.weiny@intel.com>,
"vbabka@suse.cz" <vbabka@suse.cz>,
"pierre.langlois@arm.com" <pierre.langlois@arm.com>,
"jeffxu@chromium.org" <jeffxu@chromium.org>,
"linus.walleij@linaro.org" <linus.walleij@linaro.org>,
"lorenzo.stoakes@oracle.com" <lorenzo.stoakes@oracle.com>,
"kees@kernel.org" <kees@kernel.org>,
"ryan.roberts@arm.com" <ryan.roberts@arm.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"jannh@google.com" <jannh@google.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"will@kernel.org" <will@kernel.org>,
"qperret@google.com" <qperret@google.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"broonie@kernel.org" <broonie@kernel.org>,
"x86@kernel.org" <x86@kernel.org>
Subject: Re: [RFC PATCH v5 00/18] pkeys-based page table hardening
Date: Wed, 20 Aug 2025 16:18:19 +0000 [thread overview]
Message-ID: <3c18d1f1e94d3491410168e37cdf67e9e471649e.camel@intel.com> (raw)
In-Reply-To: <5b5455eb-e649-4b20-8aad-6d7f5576a84a@arm.com>
On Wed, 2025-08-20 at 18:01 +0200, Kevin Brodsky wrote:
> Apologies, Thunderbird helpfully decided to wrap around that table...
> Here's the unmangled table:
>
> +-------------------+----------------------------------+------------------+---------------+
> > Benchmark | Result Class | Without batching | With batching |
> +===================+==================================+==================+===============+
> > mmtests/kernbench | real time | 0.32% | 0.35% |
> > | system time | (R) 4.18% | (R) 3.18% |
> > | user time | 0.08% | 0.20% |
> +-------------------+----------------------------------+------------------+---------------+
> > micromm/fork | fork: h:0 | (R) 221.39% | (R) 3.35% |
> > | fork: h:1 | (R) 282.89% | (R) 6.99% |
> +-------------------+----------------------------------+------------------+---------------+
> > micromm/munmap | munmap: h:0 | (R) 17.37% | -0.28% |
> > | munmap: h:1 | (R) 172.61% | (R) 8.08% |
> +-------------------+----------------------------------+------------------+---------------+
> > micromm/vmalloc | fix_size_alloc_test: p:1, h:0 | (R) 15.54% | (R) 12.57% |
Both this and the previous one have the 95% confidence interval. So it saw a 16%
speed up with direct map modification. Possible?
> > | fix_size_alloc_test: p:4, h:0 | (R) 39.18% | (R) 9.13% |
> > | fix_size_alloc_test: p:16, h:0 | (R) 65.81% | 2.97% |
> > | fix_size_alloc_test: p:64, h:0 | (R) 83.39% | -0.49% |
> > | fix_size_alloc_test: p:256, h:0 | (R) 87.85% | (I) -2.04% |
> > | fix_size_alloc_test: p:16, h:1 | (R) 51.21% | 3.77% |
> > | fix_size_alloc_test: p:64, h:1 | (R) 60.02% | 0.99% |
> > | fix_size_alloc_test: p:256, h:1 | (R) 63.82% | 1.16% |
> > | random_size_alloc_test: p:1, h:0 | (R) 77.79% | -0.51% |
> > | vm_map_ram_test: p:1, h:0 | (R) 30.67% | (R) 27.09% |
> +-------------------+----------------------------------+------------------+---------------+
Hmm, still surprisingly low to me, but ok. It would be good have x86 and arm
work the same, but I don't think we have line of sight to x86 currently. And I
actually never did real benchmarks.
next prev parent reply other threads:[~2025-08-20 20:50 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-15 8:54 [RFC PATCH v5 00/18] pkeys-based page table hardening Kevin Brodsky
2025-08-15 8:54 ` [RFC PATCH v5 01/18] mm: Introduce kpkeys Kevin Brodsky
2025-08-15 8:54 ` [RFC PATCH v5 02/18] set_memory: Introduce set_memory_pkey() stub Kevin Brodsky
2025-08-15 8:54 ` [RFC PATCH v5 03/18] arm64: mm: Enable overlays for all EL1 indirect permissions Kevin Brodsky
2025-08-15 8:54 ` [RFC PATCH v5 04/18] arm64: Introduce por_elx_set_pkey_perms() helper Kevin Brodsky
2025-08-15 8:54 ` [RFC PATCH v5 05/18] arm64: Implement asm/kpkeys.h using POE Kevin Brodsky
2025-08-15 8:55 ` [RFC PATCH v5 06/18] arm64: set_memory: Implement set_memory_pkey() Kevin Brodsky
2025-08-15 8:55 ` [RFC PATCH v5 07/18] arm64: Reset POR_EL1 on exception entry Kevin Brodsky
2025-08-15 8:55 ` [RFC PATCH v5 08/18] arm64: Context-switch POR_EL1 Kevin Brodsky
2025-08-15 8:55 ` [RFC PATCH v5 09/18] arm64: Enable kpkeys Kevin Brodsky
2025-08-15 8:55 ` [RFC PATCH v5 10/18] mm: Introduce kernel_pgtables_set_pkey() Kevin Brodsky
2025-08-15 8:55 ` [RFC PATCH v5 11/18] mm: Introduce kpkeys_hardened_pgtables Kevin Brodsky
2025-11-28 16:44 ` Yeoreum Yun
2025-12-01 9:19 ` Kevin Brodsky
2025-08-15 8:55 ` [RFC PATCH v5 12/18] mm: Allow __pagetable_ctor() to fail Kevin Brodsky
2025-08-15 8:55 ` [RFC PATCH v5 13/18] mm: Map page tables with privileged pkey Kevin Brodsky
2025-08-15 16:37 ` Edgecombe, Rick P
2025-08-18 16:02 ` Kevin Brodsky
2025-08-18 17:01 ` Edgecombe, Rick P
2025-08-19 9:35 ` Kevin Brodsky
2025-10-01 15:28 ` David Hildenbrand
2025-10-01 17:22 ` Kevin Brodsky
2025-08-15 8:55 ` [RFC PATCH v5 14/18] arm64: kpkeys: Support KPKEYS_LVL_PGTABLES Kevin Brodsky
2025-08-15 8:55 ` [RFC PATCH v5 15/18] arm64: mm: Guard page table writes with kpkeys Kevin Brodsky
2025-08-15 8:55 ` [RFC PATCH v5 16/18] arm64: Enable kpkeys_hardened_pgtables support Kevin Brodsky
2025-08-15 8:55 ` [RFC PATCH v5 17/18] mm: Add basic tests for kpkeys_hardened_pgtables Kevin Brodsky
2025-08-15 8:55 ` [RFC PATCH v5 18/18] arm64: mm: Batch kpkeys level switches Kevin Brodsky
2025-08-15 22:21 ` kernel test robot
2025-08-20 15:53 ` [RFC PATCH v5 00/18] pkeys-based page table hardening Kevin Brodsky
2025-08-20 16:01 ` Kevin Brodsky
2025-08-20 16:18 ` Edgecombe, Rick P [this message]
2025-08-21 7:23 ` Kevin Brodsky
2025-08-21 17:29 ` Yang Shi
2025-08-25 7:31 ` Kevin Brodsky
2025-08-26 19:18 ` Yang Shi
2025-08-27 16:09 ` Kevin Brodsky
2025-08-29 22:31 ` Yang Shi
2025-09-18 14:15 ` Kevin Brodsky
2025-09-18 14:57 ` Will Deacon
2025-10-01 12:22 ` Kevin Brodsky
2025-09-18 17:31 ` Edgecombe, Rick P
2025-10-01 12:41 ` Kevin Brodsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3c18d1f1e94d3491410168e37cdf67e9e471649e.camel@intel.com \
--to=rick.p.edgecombe@intel.com \
--cc=akpm@linux-foundation.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=ira.weiny@intel.com \
--cc=jannh@google.com \
--cc=jeffxu@chromium.org \
--cc=joey.gouly@arm.com \
--cc=kees@kernel.org \
--cc=kevin.brodsky@arm.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=luto@kernel.org \
--cc=maz@kernel.org \
--cc=mbland@motorola.com \
--cc=peterz@infradead.org \
--cc=pierre.langlois@arm.com \
--cc=qperret@google.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=tglx@linutronix.de \
--cc=vbabka@suse.cz \
--cc=will@kernel.org \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.