[PATCH] D73010: [llvm-lto2] By default, use two threads for ThinLTO backend.

[Yuanfang Chen via Phabricator via llvm-commits]

ychen added a comment.

In D73010#1828880 <https://reviews.llvm.org/D73010#1828880>, @evgeny777 wrote:

> Honestly, this looks weird  (why 2 threads not 1 for example)?


1 feels very special for multithreading code. I've seen code with separate paths for 1 and > 1, although I'm not aware of any similar code for ThinLTO.

> Also for anyone running lto on multicore machine results would be surprising at the very least.

Could you please elaborate a bit on this? Correct me if I'm wrong, my understanding is that this does not change results and llvm-lto2 which is usually for testing. It feels not very sensible to me that by default we need to activate all cores (also for Docker, each container has all the cores available.) to run the backend since there are only a few compile units for the common case. So the worst case would be <num of containers> * <lit -j> * <num of cores>.

> What's the value of `cat /proc/sys/kernel/threads-max` on build bot? On my machine it is ~84K, which seems enough even for lit/lto being run on 64 cores.

Sorry, I didn't make myself clear. Memory saturates first because of the high number of threads. `/proc/sys/kernel/threads-max` should be large enough usually.

> Also where exactly are you getting EAGAIN (sys call, library call)? You can try getting libstdc++.so.6 from build bot and disassembling it on reported offset.

>From the stack trace,  libstdc++.so throws it. Thanks for the suggestion. I think it is a great way to diagnose the issue.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D73010/new/

https://reviews.llvm.org/D73010