[all-commits] [llvm/llvm-project] 681423: [LLD][ELF] Support --[no-]mmap-output-file with F_...

[Nick Terrell via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 68142324290f2932df0e271747cdccc371d6dded
      https://github.com/llvm/llvm-project/commit/68142324290f2932df0e271747cdccc371d6dded
  Author: Nick Terrell <terrelln at fb.com>
  Date:   2019-10-29 (Tue, 29 Oct 2019)

  Changed paths:
    M lld/ELF/Config.h
    M lld/ELF/Driver.cpp
    M lld/ELF/Options.td
    M lld/ELF/Writer.cpp
    M lld/test/ELF/silent-ignore.test
    M llvm/include/llvm/Support/FileOutputBuffer.h
    M llvm/lib/Support/FileOutputBuffer.cpp
    M llvm/unittests/Support/FileOutputBufferTest.cpp

  Log Message:
  -----------
  [LLD][ELF] Support --[no-]mmap-output-file with F_no_mmap

Summary:
Add a flag `F_no_mmap` to `FileOutputBuffer` to support
`--[no-]mmap-output-file` in ELF LLD. LLD currently explicitly ignores
this flag for compatibility with GNU ld and gold.

We need this flag to speed up link time for large binaries in certain
scenarios. When we link some of our larger binaries we find that LLD
takes 50+ GB of memory, which causes memory pressure. The memory
pressure causes the VM to flush dirty pages of the output file to disk.
This is normally okay, since we should be flushing cold pages. However,
when using BtrFS with compression we need to write 128KB at a time when
we flush a page. If any page in that 128KB block is written again, then
it must be flushed a second time, and so on. Since LLD doesn't write
sequentially this causes write amplification. The same 128KB block will
end up being flushed multiple times, causing the linker to many times
more IO than necessary. We've observed 3-5x faster builds with
-no-mmap-output-file when we hit this scenario.

The bad scenario only applies to compressed filesystems, which group
together multiple pages into a single compressed block. I've tested
BtrFS, but the problem will be present for any compressed filesystem
on Linux, since it is caused by the VM.

Silently ignoring --no-mmap-output-file caused a silent regression when
we switched from gold to lld. We pass --no-mmap-output-file to fix this
edge case, but since lld silently ignored the flag we didn't realize it
wasn't being respected.

Benchmark building a 9 GB binary that exposes this edge case. I linked 3
times with --mmap-output-file and 3 times with --no-mmap-output-file and
took the average. The machine has 24 cores @ 2.4 GHz, 112 GB of RAM,
BtrFS mounted with -compress-force=zstd, and an 80% full disk.

| Mode    | Time  |
|---------|-------|
| mmap    | 894 s |
| no mmap | 126 s |

When compression is disabled, BtrFS performs just as well with and
without mmap on this benchmark.

I was unable to reproduce the regression with any binaries in
lld-speed-test.

Reviewed By: ruiu, MaskRay

Differential Revision: https://reviews.llvm.org/D69294