[m-rev.] for review: nightly test improvements

[Fergus Henderson]

On 02-Aug-2001, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> On 02-Aug-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > -lockfile=$DIR/lockfile
> > +lockfile=$HOSTDIR/lockfile
> >  if [ -f $lockfile ]; then
> > -	echo "Directory $DIR is locked:" 1>&2
> > +	echo "Directory $HOSTDIR is locked:" 1>&2
> 
> There is no reason why you should not want to run bootchecks in parallel
> in two test directories, except performance on uniprocessors.

The same performance issue applies to multiprocessors too.  For
multiprocessors we already use most of the machine's resources by running
with -jN.  The settings for the -j parameter are designed to use as much
of the machine's resources as is reasonable, so we don't want to run two
tests in parallel -- that would really start to make the machine unusable.

Anyway, part of this diff was changing things so that the code for running a
test does rm -rf on all the nightly test build directories for that host.
Running two nightly tests in parallel isn't going to be very helpful if
the second one removes all of the files that the first one is working on.

> The locking
> should not be needed for the installation part either if different test
> directories install distinct sets of files. I think directories that differ in
> branch do. Directories that differ in C compiler do not, but maybe they should.

Actually they do:

 | case "$C_COMPILER" in
 |         gcc)    ;;
 |         *)      INSTALL_DIR="$INSTALL_DIR-$C_COMPILER" ;;
 | esac

But for the reasons described above I think it's best to lock for the host
rather than just locking for the build directory.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------