Hi! On 2023-05-05T10:55:41+0200, I wrote: > [Putting Bernhard, Honza, Segher in CC, as they are eager to test this, > based on recent comments on IRC.] ;-P > First, establish the parallel testing infrastructure -- while still > hard-coding the number of parallel slots to one. > OK to push the attached > "Support parallel testing in libgomp, part I [PR66005]"? On top of that, second, enable parallel testing. > On 2015-05-08T10:40:02+0200, I wrote: >> On Thu, 7 May 2015 13:39:40 +0200, Jakub Jelinek wrote: >>> On Thu, May 07, 2015 at 01:26:57PM +0200, Rainer Orth wrote: >>> 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. >> >> Do you agree that we have two classes of test cases in libgomp: 1) test >> cases that don't place a considerably higher load on the machine compared >> to "normal" (single-threaded) execution tests, because they're just >> testing some functionality that is not expected to actively depend >> on/interfere with parallelism. If needed, and/or if not already done, >> such test cases can be parameterized (OMP_NUM_THREADS, OpenACC num_gangs, >> num_workers, vector_length clauses, and so on) for low parallelism >> levels. And, 2) test cases that place a considerably higher load on the >> machine compared to "normal" (single-threaded) execution tests, because >> they're testing some functionality that actively depends on/interferes >> with some kind of parallelism. What about marking such tests specially, >> such that DejaGnu will only ever schedule one of them for execution at >> the same time? For example, a new dg-* directive to run them wrapped >> through »flock [libgomp/testsuite/serial.lock] [a.out]« or some such? Bernhard on GCC IRC also suggested: 2023-04-25T19:32:57+0200: tschwinge, we could have a dg-do run-serial for tests that themselves occupy more/all CPUs. Or maybe it would be better to look at the testcases to see if they do that and put them in a "serial queue". I did not look, but there certainly are at least some tests which we could run in parallel. So while there certainly is potential for using more parallelism in execution testing, I've however now implemented what I'd described in : | [...] parallelize *all* compilation, while just allowing for *one* | execution test job slot. That will require some GCC DejaGnu test | harness hackery which I've [now] gotten to look into. That is, enable | the usual GCC/DejaGnu parallel testing, but also have some kind of | mutex for the execution test invocation. This has to play nicely with | DejaGnu timeout handling, etc. OK to push the attached "Support parallel testing in libgomp, part II [PR66005]"? See the Git commit log for further discussion. Grüße Thomas >>> 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. >> >> (Will again have the problem that DejaGnu doesn't provide infrastructure >> to communicate environment variables to boards in remote testing.) >> >>> 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). >> >> My rationale is: if you configure GCC to support a set of offloading >> devices (more than one), you'll also want to get the test coverage that >> indeed all these work as expected. (It currently doesn't matter, but...) >> that's something I'd like to see improved in the libgomp OpenMP >> offloading testing (once it supports more than one architecture for >> offloading). >> >>> For tests that >>> always want to test host fallback, I hope OpenACC offers clauses to force >>> the host fallback. >> >> Yes. >> >> >> Grüße, >> Thomas ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955