> On 18 Aug 2026, at 09:14, Richard Biener <[email protected]> wrote: > > On Mon, Aug 17, 2026 at 6:19 PM <[email protected]> wrote: >> >> From: Kyrylo Tkachov <[email protected]> >> >> The parallel check targets start 128 runtest instances, or as many as >> GCC_TEST_PARALLEL_SLOTS says. The -j level make was given is looked at only >> to decide whether to go parallel at all, never for how parallel to be. >> >> That constant predates machines with more cores than it, and it is now what >> limits the testsuite on them. The instances claim work from one shared >> queue, >> so the number worth starting is the number of job tokens. On a 352 core >> machine the testsuite runs 128 wide whatever -j says, and the rest of the >> machine is idle. In the other direction, make -j4 check still starts 128 >> instances, and each one reads the whole testsuite and repeats every >> effective-target probe before it can claim any work. >> >> Take the number from MFLAGS, which GNU make 4.0 and later set. A bare -j and >> older make do not give a number, and there the old default stands. An >> explicit GCC_TEST_PARALLEL_SLOTS still wins, and the per language >> check_$lang_parallelize caps still apply. >> >> On aarch64 at -j352, check-gcc falls by 24%, from a median of 118.1 s to >> 89.3 s over four interleaved rounds, with identical results in every round. >> It also runs more repeatably: the spread across rounds falls from 10.6% >> to 4.5%, and the slowest patched round is still 22% faster than the median >> unpatched one. >> >> Bootstrapped on aarch64-none-linux-gnu. Ok for trunk? > > But with low N, like -j12 my experience is that a larger > GCC_TEST_PARALLEL_SLOTS > helps because the actual time needed for the slots is not even. So > I'd rather _not_ > have this taken literally but kept at a minimum number of slots (for > example 128, but > I guess 64 might work as well). Some actual numbers might help?
I see, yes. We can take the 128 as a minimum and apply the effects of this patch only above that number. I’ve sent out a V2 with some numbers. Thanks, Kyrill > > Richard. > >> >> gcc/ChangeLog: >> >> * Makefile.in (check_p_jobs, check_p_slots): New variables. >> (check_p_subdirs): Use check_p_slots. >> >> Signed-off-by: Kyrylo Tkachov <[email protected]> >> --- >> gcc/Makefile.in | 12 +++++++++++- >> 1 file changed, 11 insertions(+), 1 deletion(-) >> >> diff --git a/gcc/Makefile.in b/gcc/Makefile.in >> index 5c7cb98d22b..ac42f54e53d 100644 >> --- a/gcc/Makefile.in >> +++ b/gcc/Makefile.in >> @@ -4760,8 +4760,18 @@ check_p_tool=$(firstword $(subst _, ,$*)) >> check_p_count=$(check_$(check_p_tool)_parallelize) >> check_p_subno=$(word 2,$(subst _, ,$*)) >> check_p_subdir=$(subst _,,$*) >> +# Number of runtest instances to start. An explicit GCC_TEST_PARALLEL_SLOTS >> +# wins. Otherwise follow the -j level make was given. The instances share >> one >> +# work queue, so the useful number of them is the number of job tokens, not >> a >> +# constant: fewer leaves the machine idle, more only adds start-up, since >> every >> +# instance reads the whole testsuite and repeats the effective-target probes >> +# before it can claim any work. GNU make 4.0 and later put the number in >> +# MFLAGS. A bare -j, and older make, do not, and there the historical >> default >> +# of 128 is kept. >> +check_p_jobs=$(patsubst -j%,%,$(filter -j%,$(MFLAGS))) >> +check_p_slots=$(if >> $(GCC_TEST_PARALLEL_SLOTS),$(GCC_TEST_PARALLEL_SLOTS),$(if >> $(check_p_jobs),$(check_p_jobs),128)) >> check_p_subdirs=$(wordlist 1,$(check_p_count),$(wordlist 1, \ >> - $(if >> $(GCC_TEST_PARALLEL_SLOTS),$(GCC_TEST_PARALLEL_SLOTS),128), \ >> + $(check_p_slots), \ >> $(one_to_9999))) >> >> # For parallelized check-% targets, this decides whether parallelization >> -- >> 2.50.1 (Apple Git-155)
