<div dir="ltr"><a href="https://codereview.appspot.com/8666045/">https://codereview.appspot.com/8666045/</a><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 29, 2013 at 4:26 PM, 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">please upload it to <a href="http://codereview.appspot.com" target="_blank">http://codereview.appspot.com</a><br>
<div class="im HOEnZb"><br>
<br>
On Fri, Apr 26, 2013 at 4:33 PM, Alexey Samsonov <<a href="mailto:samsonov@google.com">samsonov@google.com</a>> wrote:<br>
</div><div class="HOEnZb"><div class="h5">> Attaching the patch for the updated version. It adds thread-local caches for<br>
> internal_allocator to TSan threads (in the same way as we do for user<br>
> allocations).<br>
> users of internal allocator may choose not to provide thread-local cache, in<br>
> this case allocation would require a global lock.<br>
><br>
> Concerns:<br>
> * lazy initialization of internal allocator is written using atomics, can it<br>
> cause significant contention compared to the global mutex?<br>
> * TSan memory usage might increase after this change due to per-thread<br>
> caches.<br>
><br>
> On Mon, Apr 22, 2013 at 1:28 PM, Dmitry Vyukov <<a href="mailto:dvyukov@google.com">dvyukov@google.com</a>> wrote:<br>
>><br>
>><br>
>>   As per offline discussion, Alexey will measure overhead of the single<br>
>> mutex on tsan performance. If the slowdown is negligible, we can use it.<br>
>> Otherwise we need to think about per-thread caches will all the required<br>
>> machinery.<br>
>><br>
>> <a href="http://llvm-reviews.chandlerc.com/D671" target="_blank">http://llvm-reviews.chandlerc.com/D671</a><br>
><br>
><br>
><br>
> --<br>
> Alexey Samsonov, MSK<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Alexey Samsonov, MSK</div>
</div>