[PATCH] test: split test-largefile.t in multiple file
gregory.szorc at gmail.com
Sat May 17 12:58:05 CDT 2014
On 5/16/14, 3:12 PM, Mads Kiilerich wrote:
> On 05/16/2014 10:28 PM, Pierre-Yves David wrote
>>> I will still claim that when this makes a difference for your full test
>>> suite benchmarks then it is because the test scheduler is inefficient.
>> I curious about your scheduling algorithm that get a better outcome
>> for a 120 seconds tests case in a 2 minutes total test runs…
> Ok, Matt already implemented something like that in 09e1c148e847.
> After looking at your numbers, I agree it it will improve your case.
> But ... you say that running the big test alone takes 60s. And when
> running it as one of 90 jobs on your 64 cores, it takes 120s even though
> it presumably is running as the only process for the last 30s. These
> numbers surprises me. Is there a bottleneck elsewhere / do the cores
> really scale that badly / are the cores really so dual-core-fake / is 90
> jobs really the optimal number?
90 concurrent tests is significantly different from say 16 concurrent
tests. I wouldn't be surprised if 90 concurrent tests overwhelmed I/O. I
also wouldn't be surprised if the main Python process became the new
bottleneck. See the implementation of Popen4() in run-tests.py. That
sleep(.1) is almost certainly overwhelming the main test process. I
wouldn't be surprised if the thread that recorded test execution time
had its scheduled time pushed back by seconds because of all the Popen4
threads spinning. Throw in some buffering and I could see an extra 30s
overhead added there.
I would love to see measurements of different -j values on a high core
machine. My guess is we plateau somewhere. Even with infinite cores, you
can only scale a single Python process so far.
More information about the Mercurial-devel