Commit 5f4a9045 authored by Daniel Lehmann's avatar Daniel Lehmann Committed by V8 LUCI CQ

[wasm] Add PKU support histogram

This is a partial reland of https://crrev.com/c/2850932, which was
reverted because the histogram failed Chromium integration. The V8
histogram added here uses only two values (0 = no support, 1 = support),
but is declared with 3 buckets in order not not fail a DCHECK on
Chromium's side. As soon as https://crrev.com/c/2874651 lands in
Chromium, we can properly declare the histogram here with only 2 buckets,
but for now this is good enough to get early data on PKU support in
the wild.

The other part of the original reverted CL (adding PKU alloc and free
functions, and a V8 flag for PKU) was already landed again in
https://crrev.com/c/2878738

Original change's description:
> [wasm] Add PKU alloc/free and support counter
>
> To enforce W^X for the WebAssembly code space, we want to explore using
> Intel memory protection keys for userspace, also known as MPK, PKEYs, or
> PKU. Instead of flipping page protection flags with mprotect (which
> incurs a high syscall overhead; and which switches flags for the whole
> process), this associates a key with each page once, and then changes
> the permissions of that key with a fast thread-local register write.
> That is, this gives both finger-grained permissions (per-thread) and
> more performance.
>
> This CL is starts experimenting with PKUs by
> (1) trying to allocate a protection key once per {WasmEngine} in x64
> Linux systems, and
> (2) adding a counter for recording the sucess/failure of that, to assess
> the support for PKUs on the target machine.
>
> The low-level PKU allocating functions should be moved into base/platform
> long-term, but are inside wasm/ for this CL.
>
> R=clemensb@chromium.org
> CC=​jkummerow@chromium.org
>
> Bug: v8:11714
> Change-Id: Ia4858970ced4d0b84cc8c2651e86dceb532c88a7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2850932
> Commit-Queue: Daniel Lehmann <dlehmann@google.com>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74319}

Bug: v8:11714, chromium:1207318
Change-Id: I1035ac09bd7aa04584fbc5df7a408b96dd270d0a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2871451Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Commit-Queue: Daniel Lehmann <dlehmann@google.com>
Cr-Commit-Position: refs/heads/master@{#74477}
parent 25548464
......@@ -85,6 +85,11 @@ namespace internal {
HR(wasm_modules_per_engine, V8.WasmModulesPerEngine, 1, 1024, 30) \
/* bailout reason if Liftoff failed, or {kSuccess} (per function) */ \
HR(liftoff_bailout_reasons, V8.LiftoffBailoutReasons, 0, 20, 21) \
/* support for PKEYs/PKU by testing result of pkey_alloc() */ \
/* TODO(chromium:1207318): Only values 0 and 1 are actually used, but 3 */ \
/* buckets needed until {BooleanHistogram} is supported in Chromium UMA. */ \
HR(wasm_memory_protection_keys_support, V8.WasmMemoryProtectionKeysSupport, \
0, 2, 3) \
/* number of thrown exceptions per isolate */ \
HR(wasm_throw_count, V8.WasmThrowCount, 0, 100000, 30) \
/* number of rethrown exceptions per isolate */ \
......
......@@ -18,6 +18,7 @@
#include "src/strings/string-hasher-inl.h"
#include "src/utils/ostreams.h"
#include "src/wasm/function-compiler.h"
#include "src/wasm/memory-protection-key.h"
#include "src/wasm/module-compiler.h"
#include "src/wasm/module-decoder.h"
#include "src/wasm/module-instantiate.h"
......@@ -989,6 +990,15 @@ void WasmEngine::AddIsolate(Isolate* isolate) {
DCHECK_EQ(0, isolates_.count(isolate));
isolates_.emplace(isolate, std::make_unique<IsolateInfo>(isolate));
// Record memory protection key support.
if (FLAG_wasm_memory_protection_keys) {
auto* histogram =
isolate->counters()->wasm_memory_protection_keys_support();
bool has_mpk =
code_manager()->memory_protection_key_ != kNoMemoryProtectionKey;
histogram->AddSample(has_mpk ? 1 : 0);
}
// Install sampling GC callback.
// TODO(v8:7424): For now we sample module sizes in a GC callback. This will
// bias samples towards apps with high memory pressure. We should switch to
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment