On 11/23/18 2:49 PM, Jakub Jelinek wrote: > Hi! > > When running parallel make check on hosts with large amounts of CPUs (cores > and/or threads), some libgomp tests take a long time to complete. The > problem is that the libgomp runtime generally by default assumes (unless > omp_set_dynamic which checks /proc/loadavg) that it has the given cpu > resources > all for itself, it has code to limit spinning if one process uses more cpus > than available to it, but doesn't track other cpu intensive processes. > > So, when running say on 16 core 32 thread make -j32 -k check, some of the > libgomp threads may do a lot of spinning if other cpus are occupied by other > tests. > > The following patch attempts to deal with that by noticing when running > make check as parallel (-j or -jN in $(MFLAGS)) and in that case (unless > overridden) will try to use far less spinning by default (increasing > latency, but lowering CPU consumption) and, if the host has more than 8 CPUs > limit tests to 8 CPUs. It will mean somewhat smaller verification of > libgomp, if there are races or issues that could be reproduced only with > very many threads, on the other side hopefully people will burn less CPU > time when testing. > It will be desirable if people from time to time test > make check-target-libgomp > without any -jN options, that will run it with the old defaults. > > So far tested on x86_64-linux with make -j2 check-target-libgomp > and make check-target-libgomp on 16c32t (on an otherwise quiet box > with -j2 it was slightly slower, 648s vs. 618s without -j2), but > haven't yet done full parallel regtest and see if it really helped. > > Unfortunately, haven't figured out how to convince automake that I want to > write my own check-am goal, so had to drop dejagnu automake option and > add all the dejagnu stuff manually.
Do it (at least partially) address https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005 ? Martin
