Hi Jakub, > On Wed, May 29, 2019 at 04:13:41PM +0200, Rainer Orth wrote: >> Prompted by extremely long libgomp make check times due to missing >> parallelism, I noticed that the current support to restrict testcase >> parallelism only works on targets which have getconf _NPROCESSORS_ONLN. >> Instead of adding special cases for all sorts of tools to determine the >> number of cores, I found a macro in the autoconf-archive that >> encapsulates just that. >> >> The following patch makes use of that, bootstrapped without regressions >> on i386-pc-solaris2.11 and sparc-sun-solaris2.11 and checked that >> CPU_COUNT is determined correctly and the OMP_NUMP_THREADS warning >> emitted. Also rebuilt libgomp on x86_64-pc-linux-gnu and performed the >> same check. >> >> Ok for mainline? > > I'd prefer not to determine the CPU count at configure time, the build > directory can be on some network filesystem and tested sometimes on one > machine, sometimes on another one, hw can be upgraded etc.
somewhat agreed for testing on one or the other system. However, build dirs tend to be short-lived in my experience (and usually local because at least I have found builds on NFS so incredibly slow as to avoid them like the plague) and hw upgrades are relatively rare. > So, something similar to what your patch does, but don't substitute the actual > CPU count, but a command to determine the number of CPUs? I'm not convinced that would work reliably: you can easily have one set of commands on one machine, but a slightly different one on another. If we really want to go this route, that means extracting the autoconf macro's logic into a separate script and use that at make check time. Not sure if that's worth the effort, especially since we're not really interested in the exact number of cores, just small (<= 8) vs. large (> 8). Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University