[llvm-bugs] [Bug 32718] lld-created binaries do not end up in disk cache (?)

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=32718

Sean Silva <chisophugis at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #6 from Sean Silva <chisophugis at gmail.com> ---

After narrowing down, I found the behavior was quite clear. E.g. in "top", when
starting clang (and it spuriously taking multiple seconds to start) "sh" was at
100% CPU time for the entire time, not clang.
Digging in a bit with perf, the latency is actually not disk IO, but rather CPU
bottlenecked on crypto hashing of the binary in the exec(2) syscall as the
shell exec's into the clang process. 

     sys_execve
   - do_execveat_common.isra.31
      - 99.95% search_binary_handler
         - 99.95% security_bprm_check
              ima_bprm_check
              process_measurement
            - ima_collect_measurement
               - 99.93% ima_calc_file_hash
                  + 95.13% crypto_shash_update
                  + 4.78% integrity_kernel_read

(ima_calc_file_hash is:
http://src.illumos.org/source/xref/linux-master/security/integrity/ima/ima_crypto.c#439)

This also explains why `cat ./clang` can be fast while executing the file is
not.

This seems to be some sort of kernel security feature that will vary depending
on how the user's system is configured. There's nothing LLD can do about it, so
I'm closing this bug as RESOLVED INVALID. Users should talk to their system
administrator if this startup latency is affecting their productivity.

However, because this appears to be linear in the binary size, and the binary
size is mostly due to debug info, this provides good motivation for continuing
our efforts to provide a high-quality split-dwarf workflow for our users.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20170424/54843ace/attachment.html>