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