RFC [testsuite] Obey --load-average

[Daniel Santos]

On 08/03/2017 05:07 PM, Mike Stump wrote:
> On Aug 2, 2017, at 10:34 PM, Daniel Santos <daniel.santos@pobox.com> wrote:
>> I'm working on a patch to modify the testsuite to obey the
>> --load-average value if one is passed to make.
> The code seems like a reasonable approach.  Love to see numbers and test scenarios so that others can tell if you've covered their use case.  -j 100 is different from -j 4.

Well I've re-tweaked it a little to ensure more even performance with
higher numbers of CPUs, but the only way that I can think of to assure
this given the scheme is to increase the maximum *tolerance* to
something like 1 per 10 CPUs:

    set tolerance [expr {(0.0 + $num_jobs - $jobno - 1) / 10}]

Short of adding some type of IPC mechanism, I don't see another way to
do it,  but this doesn't mean that with -j 100 -l 100 we will run a load
average of 110 because only the lowest numbered jobs will use a max load
average of 110 to decide rather or not to run.  Job zero never sleeps,
job #1 will sleep until the load average drops to 109.8 or lower, job #2
until 109.7... job #98 until 100.1, and job #99 until 100.  So if one is
going for a fastest run (with 100 CPUs), something like make -j 100 -l
105 may be a good target, depending upon the statistics for when the
cost of task switching becomes greater than the loss of CPU cycles that
are unutilized due to I/O or whatever.

> People can help chip in numbers, if they have senarios that are less represented.

Yes, that is my hope.

> I don't usually share or use -l, so I don't think I can help test it.  I do wonder if it might be better to use a higher -j (I use -j somewhere between 24 and 50) and use a load limit, even in my situation.

Well that is the theory.  It would be even better if there was a way to
ask the kernel's task accounting for a load average of the last x
seconds (maybe there is and I'm just not aware of it).  Of course, when
you have 24 cores and your load average is 50, then a massive number of
cpu cycles are lost to task switching, data cache (and possibly also
instruction cache) misses, tlb misses, etc.  (Hmm, this actually makes
me wonder if a cgroup can be configured to have a much longer time slice
before being preempted by other processes in its same cgroup.)


> The only concern would be that of portability.  Seems reasonable to let it in and fix up any issues found after the fact.  I like how you ensure low impact when -l isn't used.

Yes and I've already modified the patch to disable on cygwin and mingw
because they implement getloadavg by always returning zero.  I'm sure
you've probably seen the size of Windows' PEB and TEB that it must
initialize for *each* new process -- so the fewer forks or execs on that
OS the better.  I haven't tried to test on Windows in 4-5 months, but I
have this silly hope that a recently fixed race issue will make it
better.  Last time I was only able to run a single test thread at a time. 

Other than that, I hope that it will simply be disabled where it isn't
supported.  I suspect that getloadavg will be more portable than posix
semaphores, which I would eventually like to experiment with as an
alternative to both this patch and the 10 jobs per lock file mechanism.

> Minor nit, tollerance -> tolerance.

Thank you.  Until spell checker, I used to write "paralell" and I blame
dyslexia.  I don't have dyslexia, but it's still dyslexia's fault!

I'm attaching my latest patch, which happens to be wildly broken.  I've
completed a full test run and I'm missing .sum files for libatomic,
libgom, and libitm in addition to a vast number of failed tests, but I
think I'm getting closer!

Thanks,
Daniel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: obey-load-average-20170806.patch
Type: text/x-patch
Size: 15910 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20170807/c0996fff/attachment.bin>