[cfe-dev] ld taking too much memory to link clang

[Andre Cunha]

Hello;

I made a test, and "cat /proc/`pidof ld`/oom_adj" returns 0 when ld is
running, which means ld can be killed by the oom-killer. Thus, that is not
the cause of the problem.

Maybe the kernel isn't assigning ld a score high enough to make it be
killed in an out-of-memory situation, even when it's by far the process
consuming the highest amount of memory and is ran with a niceness of 19;
however and unfortunately, I don't have time to make further tests to be
sure about this.

Anyway, I managed to link clang using gold, so I consider the problem
unexplained, but solved.

Thank you very much for the support!


On 24 January 2013 07:08, Renato Golin Linaro <renato.golin at linaro.org>wrote:

> I think the main issue is to predict how much of resources will be used
> beforehand.
>
> I agree with David that OOM shouldn't be killing processes basic on stupid
> metrics, but profiling builds might not be a bad idea.
>
> Profile Guided Build Systems could learn from very simple metrics (the
> ones exposed by Karen) and re-distribute the processes (dependency graph
> allowing) to use the resources more wisely and stop flogging the machine
> without letting it be idle either.
>
> External usage (editors, browsers, etc) can be counted as factors into the
> calculation and regarded as non-build commands that *also* consume
> resources and *also* will have similar usage across builds (a
> simplification). So, knowing which programs are open can *also* affect how
> a build will proceed.
>
> cheers,
> --renato
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>


-- 
Andre Cunha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130124/3b969c10/attachment.html>