This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Change in ld's memory use patterns from v2.10 to v2.11/2.13?
- From: "Robert D. Kennedy" <kennedy at ncdf134 dot fnal dot gov>
- To: binutils at sources dot redhat dot com
- Cc: kennedy at fnal dot gov, csieh at fnal dot gov, dawson at fnal dot gov, murat at fnal dot gov, kreymer at fnal dot gov
- Date: Fri, 30 Aug 2002 11:04:06 -0500
- Subject: Change in ld's memory use patterns from v2.10 to v2.11/2.13?
Hello,
When members of our laboratory first began upgrading from RHL 7.1 to RHL 7.3,
we noticed one difference in behavior that has delayed the upgrading of the
remainder of our machines until it is resolved.
It appears that the linker is consuming well over 2 times more resident
memory in binutils versions 2.11/2.13 than in the old binutils version 2.10.
We are building fairly large executables (50-100 MB) from a fairly large
library base (750 MB). We are very sensitive to such a large change in
behavior since this leads 'ld' to consume essentially all RAM and most swap on
our desktops, and ld fails to operate at all on laptops, while that same
operation worked smoothly with the older version. For example, linking a 120
MB executable from 750 MB of libraries consumes about 820 MB of resident
memory peak (PC with 1 GB RAM, very fast P4).
Has there been an intentional change in memory management in 'ld' between
v2.10 and v2.11? It vaguely seems that ld is memory mapping all libraries
instead of reading their tables and picking out what is needed. Is there a way
to recover the old behavior?
Unfortunately, my search of your site uncovered no related reports (lots of
spam in the mail archives). No other program demonstrates this behavior change
that we know of, however. In many cases, we were already running linux kernel
2.4.18, so the upgrade process only affected glibc and binutils. We are trying
various combinations of software versions now to further define the problem,
but are hoping to get some expert input on our working hypothesis of the cause.
Thanks much,
Rob Kennedy
Fermi National Accelerator Laboratory
Computing Division - CDF Computing and Analysis