Mmap and performance of gold

[Mikolaj Zalewski]

  Hi,
  I have seen a lot of CPU time spent inside mmap on my workstation.
To avoid blowing up the memory in 32-bit mode, gold tries to mmap only
the parts of the files that are needed, what generates lots of calls
to mmap small areas. Today, I've made a test by writing a quick patch
mmapping the whole file and not caring about alignment (it doesn't
make a difference on x86_64?) and made some measurements. Mmapping
once seems to speed up linking a 100MB, 64-bit C++ binary with gold
(values varied by some +/-0.1s between runs. I've taken the median of
three runs):

64-bit build -O2:
Mmapping all files:
real	0m3.640s
user	0m2.884s
sys	0m0.716s

Mmaping selected regions:
real	0m5.318s
user	0m2.984s
sys	0m2.312s

32-bit build -O2:
Mmapping all files:
real	0m3.787s
user	0m3.120s
sys	0m0.608s

Mmaping selected regions:
real	0m5.422s
user	0m3.124s
sys	0m2.240s

Does the attached patch make a similar difference on other systems, or
is there something strange with my kernel? Maybe we should mmap whole
files on 64-bit systems or add a command line options with a default
depending on whether the system is 64-bit. My current patch works on
architectures that don't care about alignment, but this could be
improved (the benchmark was done on a build using thin archives, so
probably the alignment change didn't affect the results in either
way).

Mikołaj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: full-mmap.patch
Type: text/x-patch
Size: 4747 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20090820/79635264/attachment.bin>