> But, I believe we also do silly > things like execute some tests serially, only taking advantage of 1/N CPU > cores in the process. This is just wasting resources. See [1] for a concrete > example.
It would be very cool if we could run mochitests inside xvfb on Linux (and maybe Mac?). But it is another point of failure -- for example, on my machine, xvfb-run causes mochitest to randomly segfault. (I think it's Firefox, not xvfb, that's dying, although I'm not positive.) Of course, investigating and implementing this would require resources, which would require us to acknowledge that we're failing by some metric, which would require us to agree on specific goals, which would require us first to agree that we should have such goals in the first place! :) On Tue, Aug 14, 2012 at 3:47 PM, Gregory Szorc <g...@mozilla.com> wrote: > On 8/14/12 12:14 PM, Ed Morley wrote: >> >> On Thursday, 9 August 2012 15:35:28 UTC+1, Justin Lebar wrote: >>> >>> Is there a plan to mitigate the coalescing on m-i? It seems like that >>> is a big part of the problem. >> >> >> Reducing the amount of coalescing permitted would just mean we end up with >> a backlog of pending tests on the repo tip - which would result in tree >> closures regardless. So other than bug 690672 making sheriffs' lives easier, >> we just need more machines in the test pool - since it's simply a case of >> demand exceeding capacity. >> >> The situation is made worse now that we're adding new platforms (OS X >> 10.7, B2G GB, B2G ICS, Android Armv6, soon OS X 10.8, Win8 desktop, Win8 >> metro) faster than we're EOLing them - and we're pushing more changes per >> day than ever before [1]. From what I understand, Apple's aggressive >> hardware cycle is also making it difficult to expand the test pool [2]. > > > Is there a tracking bug for areas where we could gain efficiency? We all > know the build phase is full of clownshoes. But, I believe we also do silly > things like execute some tests serially, only taking advantage of 1/N CPU > cores in the process. This is just wasting resources. See [1] for a concrete > example. > > Do we have data on the actual hardware load for the test runners? If we are > throwing away significant CPU cycles, etc, we could probably alleviate a lot > of the problems just with software changes. > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=686240 > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
