Changeset 269396 in webkit

Timestamp:

Nov 4, 2020 3:07:34 PM (4 years ago)

Author:

commit-queue@webkit.org

Message:

Add new build option USE(64KB_PAGE_BLOCK)
​https://bugs.webkit.org/show_bug.cgi?id=217989

Patch by Michael Catanzaro <Michael Catanzaro> on 2020-11-04
Reviewed by Yusuke Suzuki.

.:

Why do we need this option? Because JSC and bmalloc both want to know the userspace page
size at compile time, which is impossible on Linux because it's a runtime setting. We
cannot test the system page size at build time in hopes that it will be the same on the
target system, because (a) cross compiling wouldn't work, and (b) the build system could
use a different page size than the target system (which will be true for Fedora aarch64,
because Fedora is built using RHEL), so the best we can do is guess based on the target CPU
architecture. In practice, guessing works for all architectures except aarch64 (unless
unusual page sizes are used), but it fails for aarch64 because distros are split between
using 4 KB and 64 KB pages there. Most distros (including Fedora) use 4 KB, but RHEL uses
64 KB. SUSE actually supports both. Since there is no way to guess correctly, the best we
can do is provide an option for it. You should probably only use this if building for
aarch64. Otherwise, known CPUs except PowerPC will use 4 KB, while PowerPC and unknown CPUs
will use 64 KB (see wtf/PageBlock.h). aarch64 will continue to default to 4 KB because this
is a much better default on systems where it doesn't crash.

Having one flag will help avoid mistakes. E.g. both RHEL and SUSE were manually passing
-DENABLE_JIT=OFF and -DUSE_SYSTEM_MALLOC=ON, but we missed -DENABLE_C_LOOP=ON and
-DENABLE_SAMPLING_PROFILER=OFF, so wound up running with both JIT and cloop disabled, a
configuration not otherwise used on Linux (and not supported by GTK or WPE ports). It will
be easier to not mess up if we only have to pass one special build option. This will also
allow us to stop patching PageBlock.h downstream, because I don't like downstream patches
that we have to keep forever.

• Source/cmake/WebKitFeatures.cmake:

Source/WTF:

• wtf/PageBlock.h:

Location:

trunk

Files:

• ChangeLog (modified) (1 diff)
• Source/WTF/ChangeLog (modified) (1 diff)
• Source/WTF/wtf/PageBlock.h (modified) (1 diff)
• Source/cmake/WebKitFeatures.cmake (modified) (1 diff)

trunk/ChangeLog

@@ +1 @@
+2020-11-04  Michael Catanzaro  <mcatanzaro@gnome.org>
+
+        Add new build option USE(64KB_PAGE_BLOCK)
+        https://bugs.webkit.org/show_bug.cgi?id=217989
+
+        Reviewed by Yusuke Suzuki.
+
+        Why do we need this option? Because JSC and bmalloc both want to know the userspace page
+        size at compile time, which is impossible on Linux because it's a runtime setting. We
+        cannot test the system page size at build time in hopes that it will be the same on the
+        target system, because (a) cross compiling wouldn't work, and (b) the build system could
+        use a different page size than the target system (which will be true for Fedora aarch64,
+        because Fedora is built using RHEL), so the best we can do is guess based on the target CPU
+        architecture. In practice, guessing works for all architectures except aarch64 (unless
+        unusual page sizes are used), but it fails for aarch64 because distros are split between
+        using 4 KB and 64 KB pages there. Most distros (including Fedora) use 4 KB, but RHEL uses
+        64 KB. SUSE actually supports both. Since there is no way to guess correctly, the best we
+        can do is provide an option for it. You should probably only use this if building for
+        aarch64. Otherwise, known CPUs except PowerPC will use 4 KB, while PowerPC and unknown CPUs
+        will use 64 KB (see wtf/PageBlock.h). aarch64 will continue to default to 4 KB because this
+        is a much better default on systems where it doesn't crash.
+
+        Having one flag will help avoid mistakes. E.g. both RHEL and SUSE were manually passing
+        -DENABLE_JIT=OFF and -DUSE_SYSTEM_MALLOC=ON, but we missed -DENABLE_C_LOOP=ON and
+        -DENABLE_SAMPLING_PROFILER=OFF, so wound up running with both JIT and cloop disabled, a
+        configuration not otherwise used on Linux (and not supported by GTK or WPE ports). It will
+        be easier to not mess up if we only have to pass one special build option. This will also
+        allow us to stop patching PageBlock.h downstream, because I don't like downstream patches
+        that we have to keep forever.
+
+        * Source/cmake/WebKitFeatures.cmake:
+
 2020-10-30  Ryosuke Niwa  <rniwa@webkit.org>
 

trunk/Source/WTF/ChangeLog

@@ +1 @@
+2020-11-04  Michael Catanzaro  <mcatanzaro@gnome.org>
+
+        Add new build option USE(64KB_PAGE_BLOCK)
+        https://bugs.webkit.org/show_bug.cgi?id=217989
+
+        Reviewed by Yusuke Suzuki.
+
+        * wtf/PageBlock.h:
+
 2020-11-04  Aditya Keerthi  <akeerthi@apple.com>
 

trunk/Source/WTF/wtf/PageBlock.h

@@ -50 +50 @@
 #if OS(DARWIN) || PLATFORM(PLAYSTATION)
 constexpr size_t CeilingOnPageSize = 16 * KB;
+#elif USE(64KB_PAGE_BLOCK) || CPU(PPC) || CPU(PPC64) || CPU(PPC64LE) || CPU(UNKNOWN)
+constexpr size_t CeilingOnPageSize = 64 * KB;
 #elif OS(WINDOWS) || CPU(MIPS) || CPU(MIPS64) || CPU(X86) || CPU(X86_64) || CPU(ARM) || CPU(ARM64)
 constexpr size_t CeilingOnPageSize = 4 * KB;
-#elif CPU(UNKNOWN) || CPU(PPC) || CPU(PPC64) || CPU(PPC64LE)
-constexpr size_t CeilingOnPageSize = 64 * KB;
 #else
 #error Must set CeilingOnPageSize in PageBlock.h when adding a new CPU architecture!

trunk/Source/cmake/WebKitFeatures.cmake

@@ -60 +60 @@
 endmacro()
 
+# We can't use WEBKIT_OPTION_DEFINE for USE_64KB_PAGE_BLOCK because it's needed to set the default
+# value of other options. Why do we need this option? Because JSC and bmalloc both want to know the
+# userspace page size at compile time, which is impossible on Linux because it's a runtime setting.
+# We cannot test the system page size at build time in hopes that it will be the same on the target
+# system, because (a) cross compiling wouldn't work, and (b) the build system could use a different
+# page size than the target system (which will be true for Fedora aarch64, because Fedora is built
+# using RHEL), so the best we can do is guess based on based on the target CPU architecture. In
+# practice, guessing works for all architectures except aarch64 (unless unusual page sizes are
+# used), but it fails for aarch64 because distros are split between using 4 KB and 64 KB pages
+# there. Most distros (including Fedora) use 4 KB, but RHEL uses 16 KB. SUSE actually supports both.
+# Since there is no way to guess correctly, the best we can do is provide an option for it. You
+# should probably only use this if building for aarch64. Otherwise, known CPUs except PowerPC
+# will use 4 KB, while PowerPC and unknown CPUs will use 64 KB (see wtf/PageBlock.h). aarch64 will
+# continue to default to 4 KB because this is a better default on systems where it doesn't crash.
+# (Linux aarch64 is different from Apple's ARM64, which uses 16 KB.)
+option(USE_64KB_PAGE_BLOCK "Force support 64 KB userspace page size (reduces security and performance)" OFF)
+
 macro(WEBKIT_OPTION_BEGIN)
     set(_SETTING_WEBKIT_OPTIONS TRUE)
 
-    if (WTF_CPU_ARM64 OR WTF_CPU_X86_64)
+    if (USE_64KB_PAGE_BLOCK)
+        set(ENABLE_JIT_DEFAULT OFF)
+        set(ENABLE_FTL_DEFAULT OFF)
+        set(USE_SYSTEM_MALLOC_DEFAULT ON)
+        set(ENABLE_C_LOOP_DEFAULT ON)
+        set(ENABLE_SAMPLING_PROFILER_DEFAULT OFF)
+    elseif (WTF_CPU_ARM64 OR WTF_CPU_X86_64)
         set(ENABLE_JIT_DEFAULT ON)
         set(ENABLE_FTL_DEFAULT ON)