Re: [Monotone-devel] parallel-tests merged

[William Uther]

Hi,
  This is failing miserably on my mac (MacOS X 10.4, Intel mac).  I  
first tried -j4, then I scaled back to just make check.  The results  
below are for the straight "make check".

The terminal has a lot of this:

[snip]
./run_unit_tests
Running tests...
  1 _unit_tester_fail_check                       FAIL (gobbledygook:
Check failed (return value): wanted 0 got -126
stack traceback:
        [string "testlib.lua"]:96: in function 'err'
        [string "testlib.lua"]:584: in function 'post_cmd'
        [string "testlib.lua"]:712: in function <[string  
"testlib.lua"]:705>
        (tail call): ?
        ...ce/unit-tests/_unit_tester_fail_check/__driver__.lua:1:  
in main chunk
        [C]: in function 'xpcall'
        [string "testlib.lua"]:1050: in function <[string  
"testlib.lua"]:1028>
        [C]: in function 'run_tests_in_children'
        [string "testlib.lua"]:989: in function <[string  
"testlib.lua"]:804>)
[snip]

ts_stderr for that test suggests it succeeded:

/Users/willu/src/monotone/monotone-source/unit_tester: started up on  
Darwin 8.10.1 Darwin Kernel Version 8.10.1: Wed May 23 16:33:00 PDT  
2007; root:xnu-792.22.5~1/RELEASE_I386 i386
/Users/willu/src/monotone/monotone-source/unit_tester: command line:  
'/Users/willu/src/monotone/monotone-source/unit_tester',  
'_unit_tester:fail_check'
/Users/willu/src/monotone/monotone-source/unit_tester: set locale:  
LC_ALL=C
/Users/willu/src/monotone/monotone-source/unit_tester: Beginning test  
_unit_tester:fail_check
/Users/willu/src/monotone/monotone-source/unit_tester: unit_tests.cc: 
295: CHECKPOINT: checkpoint
/Users/willu/src/monotone/monotone-source/unit_tester: unit_tests.cc: 
296: CHECK FAILED: false
/Users/willu/src/monotone/monotone-source/unit_tester: unit_tests.cc: 
297: CHECK FAILED: false
/Users/willu/src/monotone/monotone-source/unit_tester: Test  
_unit_tester:fail_check succeeded.

The "STATUS" file contains the "Check failed"... stuff above and  
traceback.
The tester.log file for that test contains:

Test _unit_tester_fail_check
stdin:


runcmd: /Users/willu/src/monotone/monotone-source/unit_tester,  
local_redir = false, requested = nil
_unit_tester_fail_check:1: /Users/willu/src/monotone/monotone-source/ 
unit_tester _unit_tester:fail_check

Any thoughts?

Will        :-}


On 18/08/2007, at 1:53 AM, Zack Weinberg wrote:

> I have just merged the .parallel-tests branch to the mainline.  This
> means you can now run "make -jN check" and get some pretty hefty
> speedups.  By way of illustration - on my older, not very fast
> anymore, hyperthreaded i386 box, make -j1 check takes 20 minutes, -j2
> takes 15, -j3 is a little faster than that.  On my rather newer
> quad-core amd64, make check goes from 10 minutes at -j1 to 3:30 at
> -j4.  Full statistics are attached.
>
> I only implemented parallelism among individual testcases for Unix;
> Windows builds can still get some benefit by being able to run the
> unit tests in parallel with the integration tests (i.e. -j2 will do
> something useful, higher numbers won't).
>
> There are a few visible side effects: most important is that
> "unit_tests" is now called "unit_tester" and does nothing useful if
> you invoke it directly.  Run the unit tests by hand with
> "./run_unit_tests".  Also, there are now intermediate per-testsuite
> directories between tester_dir and the per-test directories, and the
> progress scroll now mentions each test only when it is completed (this
> is unfortunate but unavoidable).
>
> The code for all this, sadly, is a bit of a tangle: Lua calls back
> into C which forks and invokes Lua again in the child, plus lots of
> fun with file descriptors.  Improvements are welcomed.  Note that in
> the original, I was not bending over backward to avoid use of
> stdin/out/err in the child processes; in fact, I made the per-test
> logfile be stdout.  Unfortunately, this led to a bizarre bug where
> text that should have been written to stdout showed up in some other
> file altogether - but only intermittently and never under the
> debugger.  It was easier to make sure the child never touched stdout
> than to figure out what was really going on.
>
> (In case anyone is wondering why we don't use the same code path on
> Unix as we do on Windows - where, by necessity, we restart the test
> runner in a special mode in each child - it's because -j2 check on the
> hyperthreaded i386 was about two minutes faster with bare fork().)
>
> zw
> <parallel-tests-perf.txt>
> _______________________________________________
> Monotone-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/monotone-devel