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)


> >> >   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. 
> >
> > You can't assume that 64-bit machines have insane amounts of virtual
> > memory available. At minimum you need to check ulimit -v.
> 
> What are typical values for ulimit -v on a 64-bit machine?

In my experience it's typically a similar magnitude to the amount of physical 
RAM.

There are special cases (Java implementations notoriously bad), but ulimit -v 
is a good way of catching runaway processes before they hit swap excessively 
and bring the whole machine to its knees, especially on development machines.

>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.

Do you expect to be able to link images where the input files are 
significantly larger than physical ram? My guess is yes.

If you're only ever mapping one input file at once I'd guess you're probably 
ok. If you're mapping all input files simultaneously then I think you're 
liable to run into problems.

Paul


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