<div dir="ltr">And I am preparing a test branch on ghc-api/annotations to use this flag, will push it once I have checked its sanity locally<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 1, 2015 at 9:42 PM, Austin Seipp <span dir="ltr"><<a href="mailto:austin@well-typed.com" target="_blank">austin@well-typed.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Jun 1, 2015 at 2:34 PM, Joachim Breitner<br>
<<a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a>> wrote:<br>
> Hi,<br>
><br>
> Am Montag, den 01.06.2015, 14:26 -0500 schrieb Austin Seipp:<br>
>> I don't think there's any built-in way to do that in the current<br>
>> testsuite infrastructure, other than setting THREADS=1, which, if it<br>
>> isn't set already, would probably push us back over the Travis build<br>
>> limit.<br>
><br>
> we are running validate with CPU=2, which I believe translates to<br>
> THREADS=1.<br>
<br>
</span>It's actually the opposite - if you check ./validate, CPU=2 translates<br>
to THREAD=3! The reasoning is 'CPUS' is the number of physical cores<br>
you have, and it adds 1 to saturate all your cores, while the extra<br>
thread gets scheduled during I/O overlap on the underlying disk from<br>
the other threads, overall improving throughput. Normally it's a win<br>
on a completely un-contested machine, as some overlap exists.<br>
<span class=""><br>
> But we never had memory problems before, and 3GB is still quite a bit.<br>
> Are we sure that there is no bug here? Or is our official requirement<br>
> now above 3GB?<br>
<br>
</span>Well, it's possible there's something else lurking here. Maybe the<br>
merge of D913 caused things to spike for some reason, during the<br>
cleanup? Possible there was an error in the refactoring. But given<br>
that the buildbot only has 3GB and executed (in essence) with<br>
THREADS=3, I'm almost certain that it's just because they all ran at<br>
once, and the OOM killed them. We may have just gotten lucky?<br>
<br>
Also, Thomas has alerted me that the testsuite actually has an option<br>
called `high_memory_usage` which will serialize the tests and run them<br>
one at a time. So actually, that can work as a solution too!<br>
<span class="im HOEnZb"><br>
> Greetings,<br>
> Joachim<br>
><br>
> --<br>
> Joachim “nomeata” Breitner<br>
>   <a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a> • <a href="http://www.joachim-breitner.de/" target="_blank">http://www.joachim-breitner.de/</a><br>
>   Jabber: <a href="mailto:nomeata@joachim-breitner.de">nomeata@joachim-breitner.de</a>  • GPG-Key: 0xF0FBF51F<br>
>   Debian Developer: <a href="mailto:nomeata@debian.org">nomeata@debian.org</a><br>
><br>
</span><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> ghc-devs mailing list<br>
> <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
><br>
<br>
--<br>
Regards,<br>
<br>
Austin Seipp, Haskell Consultant<br>
Well-Typed LLP, <a href="http://www.well-typed.com/" target="_blank">http://www.well-typed.com/</a><br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</div></div></blockquote></div><br></div>