Re: i386 and amd64 testbeds now use NVMM

2020-08-10 Thread Andreas Gustafsson
Jukka Ruohonen wrote:
> > This reduces the time it takes to run the test suite from more than
> > 20 hours to about 3-4 hours.  Many thanks to Maxime Villard for making
> > this possible by writing NVMM.
> 
> Does this mean that the amount of test runs increases accordingly (i.e.,
> to about six runs per 24h)?

It's a bit more complicated than that.  Since multiple source versions
are tested in parallel, the i386 tests have been achieving a
throughput of more than six runs per 24 h even before the switch to
NVMM.  Using NVMM frees up a significant amount of CPU, but the builds
and the sparc tests still use as much CPU as before.  So the overall
throughput of the server has increased, but by a smaller factor than
the latency of the i386 and amd64 tests.
-- 
Andreas Gustafsson, g...@gson.org


Re: i386 and amd64 testbeds now use NVMM

2020-08-10 Thread Jukka Ruohonen
On Mon, Aug 10, 2020 at 09:19:00PM +0300, Andreas Gustafsson wrote:
> This reduces the time it takes to run the test suite from more than
> 20 hours to about 3-4 hours.  Many thanks to Maxime Villard for making
> this possible by writing NVMM.

Does this mean that the amount of test runs increases accordingly (i.e.,
to about six runs per 24h)?

- Jukka


i386 and amd64 testbeds now use NVMM

2020-08-10 Thread Andreas Gustafsson
Hi all,

The TNF testbed is now using NVMM for the i386 and amd64 tests:

  http://releng.netbsd.org/b5reports/i386/
  http://releng.netbsd.org/b5reports/amd64/

This reduces the time it takes to run the test suite from more than
20 hours to about 3-4 hours.  Many thanks to Maxime Villard for making
this possible by writing NVMM.

The switch to NVMM was made yesterday, but since the testbed may test
source versions out of order, there is not necessarily an unambiguous
transition point in terms of -current source dates.  To determine
whether a given test run was made using NVMM or not, look for "-accel
nvmm" in the qemu command line in the console log.

Some test cases that were previously failing are now passing and vice
versa.  For example, kernel/t_trapsignal:fpe_* now pass, but
lib/libpthread/t_condwait:* now fail (these contain a work-around for
the qemu timing issues of PR 43997, but now fail to detect that they
are running under qemu).
-- 
Andreas Gustafsson, g...@gson.org