This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] gold: add an option to mmap whole files (defaults to true on 64-bit linkers)


Paul Brook <paul@codesourcery.com> writes:

> On Wednesday 28 October 2009, Ian Lance Taylor wrote:
>> Mikolaj Zalewski <mikolajz@google.com> writes:
>> >   I have created a patch adding an option to mmap whole file in
>> > File_read::open and making it default on 64-bit linker builds. This
>> > seems to speed up large builds. The changes were very similar to the
>> > already existing support to open pseudo-files (for tests) with
>> > contents passed as an argument, so I've merged both features.
>> 
>> Thanks for pursuing this.
>
> You can't assume that 64-bit machines have insane amounts of virtual memory 
> available. At minimum you need to check ulimit -v.

There is a command line option, so the question here is what the
default behaviour should be.  When using --keep-files-mapped the
linker will need enough memory to mmap all the input files and the
output file.  On a 32-bit machine you only get 2G, and even ordinary
large C++ programs can exceed that when the input files are compiled
with debugging information.

What are typical values for ulimit -v on a 64-bit machine?  On all the
64-bit machines I have access to it is unlimited.  What I'm driving at
is whether we really have to check--whether for typical values of
ulimit -v we will be able link normal large C++ programs, with the
option as a fallback for extreme cases.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]