1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA256 |
3 |
|
4 |
On 12/09/12 12:58 PM, Zac Medico wrote: |
5 |
> On 09/12/2012 09:33 AM, Hans de Graaff wrote: |
6 |
>> On Wed, 2012-09-12 at 08:58 -0400, Ian Stakenvicius wrote: |
7 |
>> |
8 |
>>> So essentially what you're saying here is that it might be |
9 |
>>> worthwhile to look into parallelism as a whole and possibly |
10 |
>>> come up with a solution that combines 'emerge --jobs' and |
11 |
>>> build-system parallelism together to maximum benefit? |
12 |
>> |
13 |
>> Forget about jobs and load average, and just keep starting jobs |
14 |
>> all around until there is only 20% (or whatever tuneable amount) |
15 |
>> free memory left. As far as I can tell this is always the real |
16 |
>> bottleneck in the end. Once you hit swap overall throughput has |
17 |
>> to go down quite a bit. |
18 |
> |
19 |
> Well, I think it's still good to limit the number of jobs at |
20 |
> least, since otherwise you could become overloaded with processes |
21 |
> that don't consume a lot of memory at first but by the time they |
22 |
> complete they have consumed much more memory than desired (using |
23 |
> swap). |
24 |
|
25 |
I think this would need to be dealt with by having the parent emerge |
26 |
process monitor all children and specifically block individual |
27 |
processes (ie, 'make' , 'ld' , etc) once resources are unavailable |
28 |
until they become so. Swap may be hit by the big processes but they |
29 |
wouldn't continue to be processed while in swap, at least. |
30 |
|
31 |
I don't have a solution to the potential 'thrashing' issue, though, |
32 |
which i expect would be a problem even if there's enough memory. |
33 |
|
34 |
-----BEGIN PGP SIGNATURE----- |
35 |
Version: GnuPG v2.0.19 (GNU/Linux) |
36 |
|
37 |
iF4EAREIAAYFAlBQwFoACgkQ2ugaI38ACPAiAwD/foU8Xw1BQM3jeO6IiVfCGOnw |
38 |
xHtIufwVmMpsGVdJQRIA/3W7Utg92foSc6ZtKMzBP5Fj0qB2BXMt/RS2I4pLsCQm |
39 |
=gy9K |
40 |
-----END PGP SIGNATURE----- |