Limit the number of thinlto jobs to 8; also support limits in lld.

build/config/compiler/BUILD.gn

Index: build/config/compiler/BUILD.gn
diff --git a/build/config/compiler/BUILD.gn b/build/config/compiler/BUILD.gn
index 9426ef1836ab343f3dd3a69f822e502f91799a60..2f991023cf00d051276013da701b2960208510a8 100644
--- a/build/config/compiler/BUILD.gn
+++ b/build/config/compiler/BUILD.gn
@@ -441,13 +441,16 @@ config("compiler") {
   if (!is_debug && (allow_posix_link_time_opt || is_cfi) && !is_nacl) {
     if (use_thin_lto) {
       cflags += [ "-flto=thin" ]
-      ldflags += [
-        "-flto=thin",
+      ldflags += [ "-flto=thin" ]
 
-        # Limit the parallelism to the sweet spot on most of the machines.
-        # As of now, ThinLTO does not scale beyond 16 cores anyway.
-        "-Wl,-plugin-opt,jobs=16",
-      ]
+      # Limit the parallelism to avoid too agressive competition between
+      # linker jobs. This is still suboptimal to a potential dynamic
+      # resource allocation scheme, but should be good enough.

[Nico, 2016/12/06 21:08:48]

Shouldn't the OS scheduler be ok with linker threads being oversubscribed, as
long as there's not a lot of memory use per thread? (Is there?)

+      if (use_lld) {
+        ldflags += [ "-Wl,--thinlto-jobs=8" ]
+      } else {
+        ldflags += [ "-Wl,-plugin-opt,jobs=8" ]
+      }
     } else {
       # Note: ThinLTO does not currently have this feature implemented
       # For Full LTO, it provides a measurable runtime speedup of Chrome.