| 1 |
>>>>> On Sun, 8 Jun 2014, Jeroen Roovers wrote: |
| 2 |
|
| 3 |
> On Sun, 8 Jun 2014 09:04:20 -0400 |
| 4 |
> Rich Freeman <rich0@g.o> wrote: |
| 5 |
|
| 6 |
>> > c) EJOBS variable |
| 7 |
>> > Bug #273101 [17], gentoo-dev discussion [18] |
| 8 |
>> > - Discussion was in 2008. Is there (still) consensus? |
| 9 |
|
| 10 |
>> The only thing that might be worth noting is that distcc users may |
| 11 |
>> have an interest in distinguishing between gcc jobs and everything |
| 12 |
>> else. I once messed with dictcc with very high job numbers and it |
| 13 |
>> worked great when make hit a directory full of .c files, and not so |
| 14 |
>> great when make/ant/whatever tried to run 50 instances of java in |
| 15 |
>> parallel. |
| 16 |
|
| 17 |
> Not just distcc! We already regularly see problems with a |
| 18 |
> combination of (a) tons of RAM, (b) a dozen CPUs and (b) matching |
| 19 |
> MAKEOPTS and (d) -pipe, where concurrent linker jobs surprisingly |
| 20 |
> consume all of the RAM and one or more linker jobs segfault or get |
| 21 |
> killed. Anyone's MAKEOPTS calculation should already include all of |
| 22 |
> those factors. |
| 23 |
|
| 24 |
Also, extraction of jobs and load average from MAKEOPTS isn't so |
| 25 |
complicated. In fact, multiprocessing.eclass already provides |
| 26 |
functions makeopts_jobs() and makeopts_loadavg() for this purpose. |
| 27 |
|
| 28 |
Ulrich |
Archives