TestBot news

[Francois Gouget]

I have upgraded Debian on vm1 from 7 to 8.6 and the filesystem from ext3 
to ext4. This gets it a non-antique version of the kernel and QEMU which 
includes Huw's fix for the ntdll:exception test. So there should be one 
less unfixable failure for VMs being run on vm1.

That said I'm not really happy with the state of things on vm1: for some 
reason its reverts are much slower than they should be. For instance 
with the wvista VM doing 3 reverts in a row on otherwise idle machines 
gives me:

  vm1   56.361s  46.803s  46.569s
  vm2   10.206s   9.783s   9.912s
  vm3    9.583s   8.137s   8.004s

One could think that vm2 has much better hardware but that's just not 
the case:
                       PassMark     Disk      Disk
Host  CPU              MT    ST     Type      Speed
vm1   Xeon E3-1230v2   8855  1940   HD        130 MB/s
vm2   Opteron 6128     6959   n/a   HD Raid0  144 MB/s
vm3   Xeon E3-1226v3   7462  2127   SSD       354 MB/s

All hosts have 16 GB of RAM. So vm2 has what looks like a somewhat 
slower processor and a marginally faster disk thanks to Raid0. That 
should not be sufficient for it to be 4 times faster, particularly given 
that vm3 has a disk that's over twice as fast is only marginally faster 
than vm2.

Indeed during the revert vm1 shows no read traffic (lots of RAM to cache 
that), but a steady 6 MB/s stream of writes ! In contrast on vm2 writes 
quickly ramp up to 80 MB/s, then stop after ~5 seconds and QEMU just 
uses CPU for the last ~4 seconds.

vm3 also shows it's not an AMD vs Intel thing. There may be some 
missing CPU feature on vm1 but if that's the case I don't see what.

So there is still a mystery there and if anyone has an insight into it 
it would be appreciated.

Despite that I have put vm1 back to active duty. But I decided to keep 
the wvistau64 VM on the vm2 host. This means vm1 essentially only has 
one VM to take care of and since most of the time it's going to be idle 
already it should not slow jobs down.


I also applied all Windows updates up to 2016/07/25 to the w7u VM. This 
caused some new failures that Hans started tackling / fixed. Any other 
new failure on the 3 VMs affected by the upgrade (wvista, wvistau64 and 
w7u) should be fixable.

The configuration of the other two vms, wvista and wvistau64 should be 
essentially unchanged.


Finally I also performed a minor upgrade on vm3: from Debian 8.2 to 8.6. 
The goal was to see if the minor QEMU upgrade would be sufficient to get 
Windows 10 to stop crashing when running WineTest. It looks like that's 
not the case. So the next step will be to grab QEMU 2.7 from the Debian 
BackPorts but there's a dumb command line incompatibility with libvirt 
1.2.9 and there's no easily installable alternative :-( Fortunately I 
have a qemu wrapper script that should bridge the gap.


-- 
Francois Gouget <fgouget at codeweavers.com>