<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 8, 2016 at 3:24 PM, Rui Ueyama via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I don't know if it could theoretically make it faster. I think that if your write to a mmap'ed buffer actually have to hit a disk, that access blocks the thread, but as we only write to a mmap'ed area, so it virtually never blocks for our case, no?</div></blockquote><div><br></div><div>It will block in at least two situations:</div><div><br></div><div>- when faulting in a page for the first time, the kernel will at least have to zero it and create page table entries. Thankfully this doesn't hit disk (assuming plenty of memory), but does require the kernel to dig up a zeroed page or zero a free page and twiddle page tables; this happens under the address space lock IIRC so it may present a bottleneck if we need to write in parallel. This could be substantially mitigated with large pages, but we cannot rely on those across platforms.</div><div><br></div><div>- when closing the file, on Unix the close() will block waiting for the file to be written to disk. And in fact the kernel likely will only start writing to disk when the close() is called (I have observed this in test cases). With write, the kernel has already started the I/O operation by the time the write returns. Hence write() will likely result in better pipelining of I/O with the CPU effort.</div><div><br></div><div>-- Sean Silva</div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 8, 2016 at 3:15 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The attached patch changes lld to use posix_memalign + write instead of mmap.<br>
<br>
When linking "small" binaries like clang there is almost no<br>
difference. When linking scylladb I get a 1.019X slowdown when writing<br>
to tmpfs and a 1.040 speedup when writing to btrfs.<br>
<br>
At this stage I would say this just shows there is potential, but we<br>
have to at least benchmark this on a few filesystems.<br>
<br>
It would also be interesting to try doing one write for each section.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div></div>