[Webkit-unassigned] [Bug 187254] New: [CMake] Use JOB_POOLS to avoid memory-hungry linker processes running at the same time
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Mon Jul 2 09:44:42 PDT 2018
https://bugs.webkit.org/show_bug.cgi?id=187254
Bug ID: 187254
Summary: [CMake] Use JOB_POOLS to avoid memory-hungry linker
processes running at the same time
Product: WebKit
Version: Other
Hardware: Unspecified
OS: Unspecified
Status: NEW
Severity: Normal
Priority: P2
Component: Tools / Tests
Assignee: webkit-unassigned at lists.webkit.org
Reporter: aperez at igalia.com
CC: lforschler at apple.com
Ninja supports the so called “job pools”, to which targets can be
assigned. A job pool allows limiting the amount of parallel jobs
that will run in parallel:
https://ninja-build.org/manual.html#ref_pool
CMake supports configuring job pools, even when they are only used
by the Ninja build backend:
https://cmake.org/cmake/help/v3.3/prop_gbl/JOB_POOLS.html
Using this we could limit the amount of parallel linker processes
which are run at the same time. This is particularly important to
avoid OOM situations when linking in non-release builds.
My proposal is doing something like the following in our CMake
build files:
set_property(GLOBAL PROPERTY JOB_POOLS
release_link_jobs=4
debug_link_jobs=2)
if (${CMAKE_BUILD_TYPE} STREQUAL "Release")
set(CMAKE_JOB_POOL_LINK release_link_jobs)
else ()
set(CMAKE_JOB_POOL_LINK debug_link_jobs)
endif ()
My tests in a build machine which hosts an EWS and that I use also
for development (so there are sometimes two debug builds running
in parallel) show that the above would avoid hitting OOM situations.
Opinions?
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180702/e126847a/attachment.html>
More information about the webkit-unassigned
mailing list