This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [libgomp, testsuite] Support parallel testing in libgomp (PR libgomp/66005)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Rainer Orth <ro at CeBiTec dot Uni-Bielefeld dot DE>, Thomas Schwinge <thomas at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 7 May 2015 13:39:40 +0200
- Subject: Re: [libgomp, testsuite] Support parallel testing in libgomp (PR libgomp/66005)
- Authentication-results: sourceware.org; auth=none
- References: <yddlhh0hblq dot fsf at lokon dot CeBiTec dot Uni-Bielefeld dot DE>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Thu, May 07, 2015 at 01:26:57PM +0200, Rainer Orth wrote:
> As reported in the PR, with the addition of all those OpenACC tests,
> libgomp make check times have skyrocketed since the testsuite is still
> run sequentially.
>
> Even on a reasonably fast x86 machine (4 x 2.0 Ghz Xeon E7450) the run
> takes 4286 seconds.
>
> On slower sparc boxes (1.2 GHz UltraSPARC-T2) we're at 29406 seconds,
> compared to 7825 seconds on the 4.9 branch.
>
> Thus, the libgomp tests massively slow down the whole testsuite run,
> being the last part to finish.
>
> Fixing this proved trivial: I managed to almost literally copy the
> solution from libstdc++-v3/testsuite/Makefile.am, with a minimal change
> to libgomp.exp so the generated libgomp-test-support.exp file is found
> in both the sequential and parallel cases. This isn't an issue in
> libstdc++ since all necessary variables are stored in a single
> site.exp.
It is far from trivial though.
The point is that most of the OpenMP tests are parallelized with the
default OMP_NUM_THREADS, so running the tests in parallel oversubscribes the
machine a lot, the higher number of hw threads the more.
If we go forward with some parallelization of the tests, we at least should
try to export something like OMP_WAIT_POLICY=passive so that the
oversubscribed machine would at least not spend too much time in spinning.
And perhaps reconsider running all OpenACC threads 3 times, just allow
user to select which offloading target they want to test (host fallback,
the host nonshm hack, PTX, XeonPHI in the future?), and test just that
(that is pretty much how OpenMP offloading testing works). For tests that
always want to test host fallback, I hope OpenACC offers clauses to force
the host fallback.
Jakub