<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 1, 2015 at 11:22 AM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">----- Original Message -----<br>
> From: "Rui Ueyama" <<a href="mailto:ruiu@google.com">ruiu@google.com</a>><br>
> To: "Hal Finkel" <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>><br>
> Cc: "LLVM Developers" <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>>, "Rafael Espindola" <<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>><br>
</span><span class="">> Sent: Thursday, October 1, 2015 12:55:20 PM<br>
> Subject: Re: lld and thread over-subscription<br>
><br>
><br>
</span><span class="">> I honestly think that the ulimit of 1024 max threads is too strict<br>
> for 48 core machine. Processes are independent each other, so it is<br>
> not strange for them to spawn as many threads as the number of<br>
> cores.<br>
<br>
</span>It is an understandable misconfiguration, but not something desirable in production.<br>
<span class=""><br>
> What's the reason you cannot increase the limit?<br>
><br>
<br>
</span>It is a soft limit, and I can. Running 'ulimit -u 3072' and then re-running lit causes these failures to go away. My concern is that a soft process limit of 1024 is a common default (at least on any RedHat-derived Linux distribution) regardless of the number of cores on the machine. And, obviously, parallel makes are still very common.<br>
<br>
Regardless, do you think it would be reasonable for lit to adjust the soft process limit by default to avoid these kinds of issues, at least when running our regression tests?<br></blockquote><div><br></div><div>Yes, I do. If we can avoid the issue by adjusting the soft limit in lit, I don't see any reason to not do that.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks again,<br>
Hal<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> On Thu, Oct 1, 2015 at 10:26 AM, Hal Finkel < <a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a> ><br>
> wrote:<br>
><br>
><br>
><br>
><br>
> ----- Original Message -----<br>
> > From: "Rui Ueyama" < <a href="mailto:ruiu@google.com">ruiu@google.com</a> ><br>
> > To: "Hal Finkel" < <a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a> ><br>
> > Cc: "LLVM Developers" < <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a> >, "Rafael<br>
> > Espindola" < <a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a> ><br>
> > Sent: Thursday, October 1, 2015 11:46:05 AM<br>
> > Subject: Re: lld and thread over-subscription<br>
> ><br>
> > On Thu, Oct 1, 2015 at 9:35 AM, Hal Finkel < <a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a> ><br>
> > wrote:<br>
> ><br>
> > Hi Rui, et al.,<br>
> ><br>
> > I was experimenting yesterday with building lld on my POWER7<br>
> > PPC64/Linux machine, and ran into an unfortunate problem. When<br>
> > running the regressions tests under lit, almost all of the tests<br>
> > fail like this:<br>
> ><br>
> > terminate called after throwing an instance of 'std::system_error'<br>
> > what(): Resource temporarily unavailable<br>
> > ...<br>
> > 5 libc.so.6 0x00000080b7847238 abort + 4293480680<br>
> > 6 libstdc++.so.6 0x00000fff94f0f004<br>
> > __gnu_cxx::__verbose_terminate_handler() + 4294099316<br>
> > 7 libstdc++.so.6 0x00000fff94f0bc84<br>
> > 8 libstdc++.so.6 0x00000fff94f0bccc std::terminate() + 4294087956<br>
> > 9 libstdc++.so.6 0x00000fff94f0c0c4 __cxa_throw + 4294088780<br>
> > 10 libstdc++.so.6 0x00000fff94f816e0 std::__throw_system_error(int)<br>
> > +<br>
> > 4294526808<br>
> > 11 libstdc++.so.6 0x00000fff94f83d30<br>
> > std::thread::_M_start_thread(std::shared_ptr<std::thread::_Impl_base>)<br>
> > + 4294534936<br>
> > 12 lld 0x000000001002a278<br>
> > ...<br>
> ><br>
> > which seems to indicate a core problem here with dealing with<br>
> > thread-resource exhaustion. For almost all tests, running them<br>
> > individually (or using lit -j 1) works without a problem. We could<br>
> > deal with this by limiting the number of threads lld uses when<br>
> > running regression tests, or limit the number of threads that lit<br>
> > uses when running lld tests (as we currently do with the OpenMP<br>
> > runtime tests), but I'm somewhat concerned that users will run into<br>
> > this program regardless with heavily-parallelized builds.<br>
> ><br>
> > We could try to catch exceptions that otherwise come from<br>
> > ThreadPoolExecutor's constructor, but do we compile with exceptions<br>
> > enabled?<br>
> ><br>
> > I guess we do not want to enable exceptions to deal with the issue.<br>
> > Are COFF tests failing, or just ELF tests? If ELF tests for the old<br>
> > LLD are failing, the best way would be to not use threads in the<br>
> > old<br>
> > LLD. It has lingering threading issues.<br>
> ><br>
><br>
> To provide a data point; my default environment has this:<br>
><br>
> $ ulimit -a | grep proc<br>
> max user processes (-u) 1024<br>
><br>
> This machine has 48 cores, so with lit running 48 tests leaves each<br>
> test with only about 20 available threads, much less than the 48<br>
> each test believes it can use.<br>
><br>
> This is somewhat non-deterministic, but I just reran things both<br>
> ways, and here's what I see:<br>
><br>
> During my last run, these tests fail when running under lit with many<br>
> parallel tests, but do not fail when run otherwise:<br>
><br>
> lld :: elf2/basic.s<br>
> lld :: elf/AArch64/general-dyn-tls-0.test<br>
> lld :: elf/AArch64/initial-exec-tls-0.test<br>
> lld :: elf/AArch64/rel-prel32-overflow.test<br>
> lld :: elf/AArch64/rel-prel64.test<br>
> lld :: elf/AMDGPU/hsa.test<br>
> lld :: elf/ARM/arm-symbols.test<br>
> lld :: elf/ARM/dynamic-symbols.test<br>
> lld :: elf/ARM/entry-point.test<br>
> lld :: elf/ARM/exidx.test<br>
> lld :: elf/ARM/header-flags.test<br>
> lld :: elf/ARM/mapping-code-model.test<br>
> lld :: elf/ARM/mapping-symbols.test<br>
> lld :: elf/ARM/missing-symbol.test<br>
> lld :: elf/ARM/plt-dynamic.test<br>
> lld :: elf/ARM/plt-ifunc-interwork.test<br>
> lld :: elf/ARM/plt-ifunc-mapping.test<br>
> lld :: elf/ARM/rel-arm-call.test<br>
> lld :: elf/ARM/rel-arm-jump24-veneer-b.test<br>
> lld :: elf/ARM/rel-arm-mov.test<br>
> lld :: elf/ARM/rel-arm-prel31.test<br>
> lld :: elf/ARM/rel-arm-target1.test<br>
> lld :: elf/ARM/rel-arm-thm-interwork.test<br>
> lld :: elf/ARM/undef-lazy-symbol.test<br>
> lld :: elf/Hexagon/dynlib-data.test<br>
> lld :: elf/Mips/exe-dynamic.test<br>
> lld :: elf/Mips/exe-dynsym.test<br>
> lld :: elf/Mips/exe-fileheader-64.test<br>
> lld :: elf/Mips/exe-fileheader-micro-64.test<br>
> lld :: elf/Mips/exe-fileheader-n32.test<br>
> lld :: elf/Mips/exe-got-micro.test<br>
> lld :: elf/Mips/exe-got.test<br>
> lld :: elf/Mips/got16-2.test<br>
> lld :: elf/Mips/got16-micro.test<br>
> lld :: elf/Mips/got-page-32-micro.test<br>
> lld :: elf/Mips/got-page-64-micro.test<br>
> lld :: elf/Mips/got-page-64.test<br>
> lld :: elf/X86_64/sectionchoice.test<br>
> lld :: elf/X86_64/sectionmap.test<br>
> lld :: mach-o/arm-interworking.yaml<br>
> lld :: mach-o/arm-shims.yaml<br>
> lld :: mach-o/data-only-dylib.yaml<br>
> lld :: mach-o/executable-exports.yaml<br>
> lld :: mach-o/exe-offsets.yaml<br>
> lld :: mach-o/exported_symbols_list-undef.yaml<br>
> lld :: mach-o/fat-archive.yaml<br>
> lld :: mach-o/flat_namespace_undef_error.yaml<br>
> lld :: mach-o/flat_namespace_undef_suppress.yaml<br>
> lld :: mach-o/force_load-x86_64.yaml<br>
> lld :: mach-o/got-order.yaml<br>
> lld :: mach-o/hello-world-arm64.yaml<br>
> lld :: mach-o/hello-world-armv6.yaml<br>
> lld :: mach-o/hello-world-x86_64.yaml<br>
> lld :: mach-o/hello-world-x86.yaml<br>
> lld :: mach-o/keep_private_externs.yaml<br>
> lld :: mach-o/lazy-bind-x86_64.yaml<br>
> lld :: mach-o/library-rescan.yaml<br>
> lld :: mach-o/mh_bundle_header.yaml<br>
> lld :: mach-o/mh_dylib_header.yaml<br>
> lld :: mach-o/objc_export_list.yaml<br>
> lld :: mach-o/order_file-basic.yaml<br>
> lld :: mach-o/parse-aliases.yaml<br>
> lld :: mach-o/parse-cfstring32.yaml<br>
> lld :: mach-o/parse-cfstring64.yaml<br>
> lld :: mach-o/parse-compact-unwind32.yaml<br>
> lld :: mach-o/parse-compact-unwind64.yaml<br>
> lld :: mach-o/parse-data-in-code-armv7.yaml<br>
> lld :: mach-o/parse-data-in-code-x86.yaml<br>
> lld :: mach-o/parse-data-relocs-arm64.yaml<br>
> lld :: mach-o/parse-data-relocs-x86_64.yaml<br>
> lld :: mach-o/parse-data.yaml<br>
> lld :: mach-o/parse-eh-frame-relocs-x86_64.yaml<br>
> lld :: mach-o/parse-eh-frame-x86-anon.yaml<br>
> lld :: mach-o/parse-eh-frame-x86-labeled.yaml<br>
> lld :: mach-o/parse-eh-frame.yaml<br>
> lld :: mach-o/parse-function.yaml<br>
> lld :: mach-o/parse-initializers32.yaml<br>
> lld :: mach-o/parse-initializers64.yaml<br>
> lld :: mach-o/parse-literals-error.yaml<br>
> lld :: mach-o/parse-literals.yaml<br>
> lld :: mach-o/parse-non-lazy-pointers.yaml<br>
> lld :: mach-o/parse-relocs-x86.yaml<br>
> lld :: mach-o/parse-section-no-symbol.yaml<br>
> lld :: mach-o/parse-tentative-defs.yaml<br>
> lld :: mach-o/parse-text-relocs-x86_64.yaml<br>
> lld :: mach-o/parse-tlv-relocs-x86-64.yaml<br>
> lld :: mach-o/re-exported-dylib-ordinal.yaml<br>
> lld :: mach-o/rpath.yaml<br>
> lld :: mach-o/run-tlv-pass-x86-64.yaml<br>
> lld :: mach-o/sectalign.yaml<br>
> lld :: mach-o/twolevel_namespace_undef_dynamic_lookup.yaml<br>
> lld :: mach-o/usage.yaml<br>
> lld :: mach-o/use-simple-dylib.yaml<br>
> lld :: mach-o/write-final-sections.yaml<br>
> lld :: mach-o/wrong-arch-error.yaml<br>
> lld-Unit :: CoreTests/CoreTests/Range.conversion_to_pointer_range<br>
> lld-Unit :: CoreTests/CoreTests/Range.slice<br>
> lld-Unit :: CoreTests/CoreTests/Range.user1<br>
> lld-Unit :: CoreTests/CoreTests/Range.user2<br>
><br>
> Of these, the following tests don't fail, but are reported as<br>
> 'Unresolved' (which does not happen if I run lit -j 1):<br>
><br>
> lld :: elf/ARM/mapping-code-model.test<br>
> lld :: elf/ARM/mapping-symbols.test<br>
> lld :: elf/ARM/missing-symbol.test<br>
> lld :: elf/ARM/plt-ifunc-interwork.test<br>
> lld :: elf/ARM/rel-arm-jump24-veneer-b.test<br>
> lld :: elf/Mips/exe-got-micro.test<br>
> lld :: elf/Mips/exe-got.test<br>
> lld :: elf/Mips/got16-micro.test<br>
> lld :: mach-o/parse-cfstring64.yaml<br>
> lld :: mach-o/parse-compact-unwind32.yaml<br>
> lld :: mach-o/parse-compact-unwind64.yaml<br>
> lld :: mach-o/parse-data-in-code-armv7.yaml<br>
> lld :: mach-o/parse-data-in-code-x86.yaml<br>
> lld :: mach-o/parse-data-relocs-arm64.yaml<br>
> lld :: mach-o/parse-data-relocs-x86_64.yaml<br>
> lld :: mach-o/parse-data.yaml<br>
> lld :: mach-o/parse-eh-frame-relocs-x86_64.yaml<br>
> lld :: mach-o/parse-eh-frame-x86-anon.yaml<br>
> lld :: mach-o/parse-eh-frame-x86-labeled.yaml<br>
> lld :: mach-o/parse-eh-frame.yaml<br>
> lld :: mach-o/parse-function.yaml<br>
> lld :: mach-o/parse-initializers32.yaml<br>
> lld :: mach-o/parse-initializers64.yaml<br>
> lld :: mach-o/parse-literals-error.yaml<br>
> lld :: mach-o/parse-literals.yaml<br>
> lld :: mach-o/parse-non-lazy-pointers.yaml<br>
> lld :: mach-o/parse-relocs-x86.yaml<br>
> lld :: mach-o/parse-section-no-symbol.yaml<br>
> lld :: mach-o/parse-tentative-defs.yaml<br>
> lld :: mach-o/parse-text-relocs-arm64.yaml<br>
> lld :: mach-o/parse-text-relocs-x86_64.yaml<br>
> lld :: mach-o/parse-tlv-relocs-x86-64.yaml<br>
> lld :: mach-o/rpath.yaml<br>
> lld :: mach-o/run-tlv-pass-x86-64.yaml<br>
> lld :: mach-o/twolevel_namespace_undef_dynamic_lookup.yaml<br>
> lld :: mach-o/usage.yaml<br>
> lld-Unit :: CoreTests/CoreTests/Range.conversion_to_pointer_range<br>
> lld-Unit :: CoreTests/CoreTests/Range.slice<br>
> lld-Unit :: CoreTests/CoreTests/Range.user1<br>
> lld-Unit :: CoreTests/CoreTests/Range.user2<br>
><br>
> these are listed as unresolved for the same underlying reason, for<br>
> example:<br>
><br>
> ********************<br>
> UNRESOLVED: lld-Unit :: CoreTests/CoreTests/Range.user1 (25040 of<br>
> 25181)<br>
> ******************** TEST 'lld-Unit ::<br>
> CoreTests/CoreTests/Range.user1' FAILED ********************<br>
> Exception during script execution:<br>
> Traceback (most recent call last):<br>
> File "/src/llvm/utils/lit/lit/run.py", line 166, in execute_test<br>
> result = test.config.test_format.execute(test, self.lit_config)<br>
> File "/src/llvm/utils/lit/lit/formats/googletest.py", line 113, in<br>
> execute<br>
> cmd, env=test.config.environment)<br>
> File "/src/llvm/utils/lit/lit/util.py", line 166, in executeCommand<br>
> env=env, close_fds=kUseCloseFDs)<br>
> File "/install/ppc64/Python-2.7/lib/python2.7/subprocess.py", line<br>
> 710, in __init__<br>
> errread, errwrite)<br>
> File "/install/ppc64/Python-2.7/lib/python2.7/subprocess.py", line<br>
> 1231, in _execute_child<br>
> self.pid = os.fork()<br>
> OSError: [Errno 11] Resource temporarily unavailable<br>
><br>
> Being naturally nondeterministic, running again with the default<br>
> number of parallel lit tests changes which tests fail (for example,<br>
> running a second time adds tests under COFF).<br>
><br>
> And, FWIW, these tests generally fail on my system (for reasons<br>
> seemingly unrelated to the thread/process resource issue):<br>
><br>
> lld :: Driver/lib-search.test<br>
> lld :: Driver/undef-basic.objtxt<br>
> lld :: elf2/dynamic-reloc.s<br>
> lld :: elf2/shared.s<br>
> lld :: elf2/soname.s<br>
> lld :: elf/librarynotfound.test<br>
> lld :: elf/responsefile.test<br>
> lld :: mach-o/dylib-install-names.yaml<br>
> lld :: mach-o/force_load-dylib.yaml<br>
> lld :: mach-o/lib-search-paths.yaml<br>
> lld :: mach-o/parse-text-relocs-arm64.yaml<br>
> lld :: mach-o/upward-dylib-load-command.yaml<br>
> lld-Unit :: DriverTests/DriverTests/GnuLdParserTest.AsNeeded<br>
> lld-Unit :: DriverTests/DriverTests/GnuLdParserTest.DefsymAlias<br>
> lld-Unit :: DriverTests/DriverTests/GnuLdParserTest.DefsymDecimal<br>
> lld-Unit :: DriverTests/DriverTests/GnuLdParserTest.DefsymHexadecimal<br>
> lld-Unit :: DriverTests/DriverTests/GnuLdParserTest.DefsymOctal<br>
> lld-Unit :: DriverTests/DriverTests/GnuLdParserTest.Empty<br>
> lld-Unit :: DriverTests/DriverTests/GnuLdParserTest.Entry<br>
> lld-Unit :: DriverTests/DriverTests/GnuLdParserTest.EntryJoined<br>
> lld-Unit :: DriverTests/DriverTests/GnuLdParserTest.EntryShort<br>
> lld-Unit :: DriverTests/DriverTests/GnuLdParserTest.ExportDynamic<br>
> lld-Unit :: DriverTests/DriverTests/GnuLdParserTest.Init<br>
> lld-Unit :: DriverTests/DriverTests/GnuLdParserTest.InitJoined<br>
> lld-Unit :: DriverTests/DriverTests/GnuLdParserTest.NoExportDynamic<br>
> lld-Unit :: DriverTests/DriverTests/GnuLdParserTest.NoinhibitExec<br>
> lld-Unit :: DriverTests/DriverTests/GnuLdParserTest.Output<br>
> lld-Unit :: DriverTests/DriverTests/GnuLdParserTest.OutputDefault<br>
> lld-Unit :: DriverTests/DriverTests/GnuLdParserTest.Rpath<br>
> lld-Unit :: DriverTests/DriverTests/GnuLdParserTest.RpathEq<br>
> lld-Unit :: DriverTests/DriverTests/GnuLdParserTest.SOName<br>
> lld-Unit :: DriverTests/DriverTests/GnuLdParserTest.SONameH<br>
> lld-Unit :: DriverTests/DriverTests/GnuLdParserTest.SONameSingleDash<br>
> lld-Unit :: DriverTests/DriverTests/LinkerScriptTest.Entry<br>
> lld-Unit :: DriverTests/DriverTests/LinkerScriptTest.ExprEval<br>
> lld-Unit :: DriverTests/DriverTests/LinkerScriptTest.Group<br>
> lld-Unit ::<br>
> DriverTests/DriverTests/LinkerScriptTest.IgnoreSearchDirNoStdLib<br>
> lld-Unit :: DriverTests/DriverTests/LinkerScriptTest.Input<br>
> lld-Unit :: DriverTests/DriverTests/LinkerScriptTest.Output<br>
> lld-Unit :: DriverTests/DriverTests/LinkerScriptTest.SearchDir<br>
> lld-Unit :: DriverTests/DriverTests/UniversalDriver.flavor<br>
><br>
> (it could be big-Endian issues, LLVM bugs, etc. -- I've yet to<br>
> investigate).<br>
><br>
> The easiest thing to do is to make lld tests run using lit -j 1, but<br>
> we may also want to think about how to more-gracefully handle this<br>
> situation in general, because it seems like something a user is not<br>
> unlikely to hit.<br>
><br>
> Thanks again,<br>
> Hal<br>
><br>
><br>
><br>
> ><br>
> > Thanks again,<br>
> > Hal<br>
> ><br>
> > --<br>
> > Hal Finkel<br>
> > Assistant Computational Scientist<br>
> > Leadership Computing Facility<br>
> > Argonne National Laboratory<br>
> ><br>
> ><br>
><br>
> --<br>
> Hal Finkel<br>
> Assistant Computational Scientist<br>
> Leadership Computing Facility<br>
> Argonne National Laboratory<br>
><br>
><br>
<br>
--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</div></div></blockquote></div><br></div></div>