https://bugs.winehq.org/show_bug.cgi?id=47855
Bug ID: 47855 Summary: Run tests in more than one VM at a time Product: Wine-Testbot Version: unspecified Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: unknown Assignee: wine-bugs@winehq.org Reporter: fgouget@codeweavers.com Distribution: ---
Some Wine tests have pretty stringent timing requirements:
* Some audio tests play a short sound bite and make sure the playback lasted for the expected time within a few tens of seconds as a way to ensure audio is played at the right rate. But VMs are not always very good at respecting precise timing requirements when there is other activity on the host.
* Some tests (msi) generate quite a bit of disk traffic and take a while to run. Running two of those simultaneously can sometimes push them over the 2 minutes limit, causing them to time out. That said there may be something else afoot here as these run times vary from ~20s to ~100s depending on the VM for seemingly no reason.
As a consequence the TestBot is configured to only do one thing at a time: run at most one test or revert one VM. This is at odds with hardware evolution and new TestBot requirements:
* SSDs are much faster than hard drives and thus should solve the disk bottleneck issues.
* The builds for the Wine VMs take a lot more time than just producing PE executables for the Windows VMs. To speed up compilation it is necessary to increase the parallelism which means buying a machine with as many cores as possible and assigning as many as possible to the Wine VMs.
* But while running single threaded tests in a single VM on a quad-core machine is bad enough, doing the same thing on a 16+ threads machine would truly be a waste.
So a way to be able to run tests in more than one VM at a time should be found. The first step would be to verify that these issues still exist (this means distinguishing them from the usual random failures). If they don't then problem solved!
Otherwise CPU-pinning is a solution that's usually mentioned in gaming circles. The questions are:
* Would it actually help?
* How to integrate it with the TestBot. Is this something that should be configured through Libvirt when restoring a live snapshot? Or is this something that should be defined 'statically' in the VM's configuration?
* What happens if two VMs are pinned to the same CPU core? Will Libvirt prevent us from starting both at the same time or is it up to the TestBot Engine to make sure this does not happen? How?
* What happens when a VM that's is pinned to CPU core 7 is moved to a 4 core host? Is the pinning ignored or does the administrator have to manually change its configuration?
https://bugs.winehq.org/show_bug.cgi?id=47855
Zhiyi Zhang zzhang@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zzhang@codeweavers.com
--- Comment #1 from Zhiyi Zhang zzhang@codeweavers.com --- I would vote for upgrading to SSDs. From statistics, reverting takes a very long time.
And I happens read an article about scheduling containers recently. The principles the article show should apply to VMs as well, although the exact scheme is more difficult to implement. It should give some ideas at least. https://medium.com/netflix-techblog/predictive-cpu-isolation-of-containers-a...
https://bugs.winehq.org/show_bug.cgi?id=47855
--- Comment #2 from François Gouget fgouget@codeweavers.com --- Fortunately our requirements are probably simpler than Netflix's. For instance I think in our case it would be quite alright to place a "dual-cpu" VM on a single hyperthreaded host core.
The nodeinfo and capabilities virsh commands are interesting: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/htm...
Furthermore virsh vcpupin indicates that the CPU pinning can be configured on running guests and presumably all these APIs are available through Libvirt's perl interface.
So I guess LibvirtTool could query the host's CPU and Numa information (virsh capabilities), get a list of the already running VMs (virsh list), get CPU assignments from them (virsh vcpuinfo), and set up pinning for the new VM (virsh vcpupin).
https://bugs.winehq.org/show_bug.cgi?id=47855
--- Comment #3 from François Gouget fgouget@codeweavers.com --- *** Bug 48040 has been marked as a duplicate of this bug. ***