<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 18, 2014 at 2:30 AM, Dmitry Vyukov <span dir="ltr"><<a href="mailto:dvyukov@google.com" target="_blank">dvyukov@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="adM"><div class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div>



</div></div></div>
</blockquote></div><br></div></div></div><div class="gmail_extra">Array processing is fast. Contention is slow. I would expect this to be a net win.</div><div class="gmail_extra">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.</div>
</blockquote></div><br>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.</div></div>