<html>
    <head>
      <base href="https://bugs.llvm.org/">
    </head>
    <body><span class="vcard"><a class="email" href="mailto:chisophugis@gmail.com" title="Sean Silva <chisophugis@gmail.com>"> <span class="fn">Sean Silva</span></a>
</span> changed
          <a class="bz_bug_link 
          bz_status_RESOLVED  bz_closed"
   title="RESOLVED INVALID - lld-created binaries do not end up in disk cache (?)"
   href="https://bugs.llvm.org/show_bug.cgi?id=32718">bug 32718</a>
          <br>
             <table border="1" cellspacing="0" cellpadding="8">
          <tr>
            <th>What</th>
            <th>Removed</th>
            <th>Added</th>
          </tr>

         <tr>
           <td style="text-align:right;">Status</td>
           <td>NEW
           </td>
           <td>RESOLVED
           </td>
         </tr>

         <tr>
           <td style="text-align:right;">Resolution</td>
           <td>---
           </td>
           <td>INVALID
           </td>
         </tr></table>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_RESOLVED  bz_closed"
   title="RESOLVED INVALID - lld-created binaries do not end up in disk cache (?)"
   href="https://bugs.llvm.org/show_bug.cgi?id=32718#c6">Comment # 6</a>
              on <a class="bz_bug_link 
          bz_status_RESOLVED  bz_closed"
   title="RESOLVED INVALID - lld-created binaries do not end up in disk cache (?)"
   href="https://bugs.llvm.org/show_bug.cgi?id=32718">bug 32718</a>
              from <span class="vcard"><a class="email" href="mailto:chisophugis@gmail.com" title="Sean Silva <chisophugis@gmail.com>"> <span class="fn">Sean Silva</span></a>
</span></b>
        <pre>
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:
<a href="http://src.illumos.org/source/xref/linux-master/security/integrity/ima/ima_crypto.c#439">http://src.illumos.org/source/xref/linux-master/security/integrity/ima/ima_crypto.c#439</a>)

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.</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are on the CC list for the bug.</li>
      </ul>
    </body>
</html>