[LLVMdev] multithreaded performance disaster with -fprofile-instr-generate (contention on profile counters)

[Chandler Carruth]

On Fri, Apr 18, 2014 at 2:30 AM, Dmitry Vyukov <dvyukov at google.com> wrote:

> It's not at all clear to me that this scales up (either in memory usage,
>> memory reservation, or shutdown time) to larger applications. Chrome isn't
>> a useful upper bound here.
>>
>
> Array processing is fast. Contention is slow. I would expect this to be a
> net win.
> For the additional memory consumption during final merge, we can process
> one per-thread array, unmap it, process second array, unmap it, and so on.
> This will not require bringing all the pages into memory.
>

Array processing is fast, but paging in a large % of the pages in your
address space is not at all fast. This will murder the kernel's page table,
and do other very slow things I suspect.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140418/49bf0665/attachment.html>