Skip to content

[build] Add option to limit number of link jobs #29361

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from

Conversation

roop
Copy link
Contributor

@roop roop commented Jan 22, 2020

When building llvm or Swift, linking uses much more memory than compilation, and therefore, it’s useful to limit the number of parallel jobs during linking only, as opposed to all jobs. For example, on a 4 GB RAM linux machine, building fails when two linking tasks are running in parallel, because of shortage of RAM. This is not a problem when two compiling tasks are running in parallel.

This PR enables us to call build-script like:

build-script --swift-tools-num-parallel-link-jobs 1 --llvm-num-parallel-link-jobs 1

to make it run only one link job at a time, while compilations jobs are not restricted.

Work to get parallel link jobs information into CMake / Ninja files has already been done for use with LTO. This PR just exposes that functionality in build-script for the case when LTO is not enabled.

roop added 2 commits January 22, 2020 19:59
build-script-impl (and thereby build-script) now supports these additional
arguments:

  --swift-tools-num-parallel-link-jobs <number>
  --llvm-num-parallel-link-jobs <number>
@roop roop requested a review from gottesmm January 22, 2020 20:18
@@ -640,6 +642,18 @@ function set_build_options_for_host() {
-DLLVM_BUILD_EXTERNAL_COMPILER_RT:BOOL="$(false_true ${SKIP_BUILD_COMPILER_RT})"
)

if [[ "${SWIFT_TOOLS_NUM_PARALLEL_LINK_JOBS}" != "" ]] && [[ $(is_swift_lto_enabled) == "FALSE" ]]; then
swift_cmake_options+=(
"-DSWIFT_PARALLEL_LINK_JOBS=${SWIFT_TOOLS_NUM_PARALLEL_LINK_JOBS}"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't looked at this, but I wonder if it would make sense to just have one option for this rather than have two options. Is that possible? How do we do it in the lldb case?

@compnerd
Copy link
Member

I really think that we should spell this as --swift-cmake-options=-DSWIFT_PARALLEL_LINK_JOBS=... --llvm-cmake-options=-DLLVM_PARALLEL_LINK_JOBS=.... It does not make sense to expose every single CMake option through to build-script unless we uniformly expose all options.

@gottesmm
Copy link
Contributor

@compnerd another thing to consider is why even have different ones for swift and llvm.

@compnerd
Copy link
Member

The reason for the two options is due to the out-of-tree build. If we could do unified builds, then, the LLVM option alone would be sufficient.

@gottesmm
Copy link
Contributor

@compnerd I understand that, but why shouldn't we just have a higher level option that defines it for both. I don't see why two nobs are necessary even with the out of tree build.

@compnerd
Copy link
Member

compnerd commented Jan 22, 2020

@gottesmm - oh, those options are for ease. Feel free to use the higher level option: -DCMAKE_JOB_POOLS:SRING=compile=[N];link=[M] -DCMAKE_JOB_POOL_COMPILE:STRING=compile -DCMAKE_JOB_POOL_LINK:STRING=link.

@gottesmm
Copy link
Contributor

that is my thought. Using the high level options make more sense!

@compnerd
Copy link
Member

In that case, this would just be written as --extra-cmake-args="-DCMAKE_JOB_POOLS:SRING=compile=32;link=16 -DCMAKE_JOB_POOL_COMPILE:STRING=compile -DCMAKE_JOB_POOL_LINK:STRING=link" IIRC

@compnerd
Copy link
Member

(My opinion is that this is a documentation issue, not a build-script-impl issue)

@roop
Copy link
Contributor Author

roop commented Jan 24, 2020

I didn't know about the --llvm-cmake-options / --swift-cmake-options trick - that works well, thank you. Since it's already possible to control the number of link jobs from the build script, I'll close this PR.

@compnerd:

(My opinion is that this is a documentation issue, not a build-script-impl issue)

I'd be happy to open a separate PR to document this, but I'm not sure which document this should go into.

@roop roop closed this Jan 24, 2020
@compnerd
Copy link
Member

I'd be happy to open a separate PR to document this, but I'm not sure which document this should go into.

Thank you, that would be wonderful! I think that this belongs in DeveloperTips.md

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants