On Tue, Sep 11, 2012 at 1:07 PM, Zac Medico <zmed...@gentoo.org> wrote: > On 09/11/2012 09:54 AM, Ian Stakenvicius wrote: >> At the ebuild level, certainly, but that's one of the reasons for >> EJOBS in the first place, so that it can be overridden consistently >> within a phase, if necessary for the ebuild (regardless of build >> system type), right? > > Right. I'm surprised that ELOADAVG wasn't proposed in tandem with EJOBS > though, since overloading is not a good idea, and can happen easily any > time that you doing lots of things in parallel.
I tend to agree that load average matters more, although that doesn't factor in RAM use. I don't suggest that this is something that is easily remedied, but I have run into a situation where WHAT you're doing greatly influences how many jobs you can run - distcc. I once tried to implement distcc in a fairly large cluster, and then run make with VERY high levels of parallelization - such as -j32. That worked great - if the package used C. Then portage would try to build something that used ant and suddenly the host was trying to run 32 jvms in parallel - just killing the system. Ditto for python/etc. There was no way to tell the build system to go nuts with anything using distcc but not everything else. I think this is just a fundamental limitation of make - I don't suggest that we can fix this at the portage level. However, that is a use case where WHAT you're doing influences how many jobs you can run. Rich
