Page MenuHomePhabricator

dvyukov (Dmitry Vyukov)
User

Projects

User does not belong to any projects.

User Details

User Since
Dec 6 2012, 2:31 AM (319 w, 4 d)

Recent Activity

Thu, Jan 10

dvyukov added a comment to D54889: Fiber support for thread sanitizer.

Benchmark results with clang:

Thu, Jan 10, 9:47 AM · Restricted Project

Tue, Jan 8

dvyukov added a comment to D54889: Fiber support for thread sanitizer.

I improved test execution time. On my system I got following execution times (compared to original version of code):

compilercurrentfibers
gcc 8.2100.0%98.6%
clang112.4%100.7%

"current" is compiler-rt HEAD with no local changes, or with the previous version of this change? This makes clang-compiled runtime 12% faster?
Were you able to reproduce the slowdown in https://reviews.llvm.org/D54889#1343582 with the previous version of the fibers change? What slowdown did you get?

Tue, Jan 8, 1:49 AM · Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

I improved test execution time. On my system I got following execution times (compared to original version of code):

compilercurrentfibers
gcc 8.2100.0%98.6%
clang112.4%100.7%
Tue, Jan 8, 1:44 AM · Restricted Project

Mon, Jan 7

dvyukov accepted D56238: [TSan] Support Objective-C @synchronized with tagged pointers.
Mon, Jan 7, 11:10 AM · Restricted Project

Sun, Jan 6

dvyukov added inline comments to D56238: [TSan] Support Objective-C @synchronized with tagged pointers.
Sun, Jan 6, 10:12 PM · Restricted Project

Fri, Jan 4

dvyukov added inline comments to D56238: [TSan] Support Objective-C @synchronized with tagged pointers.
Fri, Jan 4, 1:24 AM · Restricted Project
dvyukov accepted D56295: [TSan] Use switches when dealing with enums.
Fri, Jan 4, 1:10 AM · Restricted Project

Thu, Jan 3

dvyukov added a comment to D56238: [TSan] Support Objective-C @synchronized with tagged pointers.

What are tagged pointers? When they are used? What is the actual value? How does synchronized handle them? Is there a man page or something with more info? It should be included in the comment for future generations.

Thu, Jan 3, 12:55 AM · Restricted Project

Wed, Jan 2

dvyukov added a comment to D54889: Fiber support for thread sanitizer.

I've benchmarked on 350140 with host gcc version 7.3.0 (Debian 7.3.0-5), running old/new binary alternated:

Wed, Jan 2, 6:58 AM · Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

Re performance, we have this open performance regression in clang codegen which makes it harder to do analysis:
https://bugs.llvm.org/show_bug.cgi?id=39748
https://reviews.llvm.org/D54821

Wed, Jan 2, 6:22 AM · Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

I added default synchronization and flag to opt-out.

Can you swicth to it in your codebase? I would expect that you need all (or almost all) of this synchronization anyway?

Unfortunately, I can't check it. Current implementation of our codebase work fine with synchronization on fiber switch.

I plan to implement another mode when fibers are not synchronized by default, but only when they call special synchronization APIs (events, mutexes etc.). Such way I can catch more errors in code when fibers are running in the same thread only by chance. In order to implement it, I need some way to opt-out of synchronization in tsan.

Wed, Jan 2, 6:22 AM · Restricted Project
dvyukov accepted D56157: [sanitizer_common] Implement popen, popenve, pclose interceptors.
Wed, Jan 2, 5:40 AM
dvyukov added inline comments to D56157: [sanitizer_common] Implement popen, popenve, pclose interceptors.
Wed, Jan 2, 4:01 AM

Sun, Dec 30

dvyukov added a comment to D56157: [sanitizer_common] Implement popen, popenve, pclose interceptors.

This needs some tests, at least to exercise interceptors code once.

Sun, Dec 30, 8:05 PM
dvyukov accepted D56159: [MSan] Handle llvm.is.constant intrinsic.

Nice! Interesting nobody reported this false positive on user-space code.

Sun, Dec 30, 6:03 AM

Dec 22 2018

dvyukov accepted D55959: [TSan] Enable detection of lock-order-inversions for Objective-C @synchronized.

I would like to land this and fix @synchronized with tagged pointers in a follow-up since more discussion is required what we actually want it to do.

Dec 22 2018, 12:01 AM · Restricted Project

Dec 21 2018

dvyukov accepted D55075: [TSan] Remove ignore_interceptors_accesses flag.
Dec 21 2018, 11:44 PM · Restricted Project

Dec 20 2018

dvyukov added inline comments to D55075: [TSan] Remove ignore_interceptors_accesses flag.
Dec 20 2018, 10:21 PM · Restricted Project
dvyukov added inline comments to D55959: [TSan] Enable detection of lock-order-inversions for Objective-C @synchronized.
Dec 20 2018, 10:15 PM · Restricted Project

Dec 19 2018

dvyukov committed rCRT349609: tsan: align default value of detect_deadlocks flag with actual behavior.
tsan: align default value of detect_deadlocks flag with actual behavior
Dec 19 2018, 1:38 AM
dvyukov committed rL349609: tsan: align default value of detect_deadlocks flag with actual behavior.
tsan: align default value of detect_deadlocks flag with actual behavior
Dec 19 2018, 1:38 AM
dvyukov closed D55846: [TSan] Align default value of `detect_deadlocks` flag with actual behavior.

Merged as 349609.

Dec 19 2018, 1:38 AM · Restricted Project
dvyukov accepted D55846: [TSan] Align default value of `detect_deadlocks` flag with actual behavior.

Thanks!
Merging this now.

Dec 19 2018, 1:36 AM · Restricted Project

Dec 18 2018

dvyukov added a comment to D54889: Fiber support for thread sanitizer.

FTR, here is current code:

Dec 18 2018, 8:02 AM · Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

I added default synchronization and flag to opt-out.

Dec 18 2018, 7:36 AM · Restricted Project
dvyukov added inline comments to D54889: Fiber support for thread sanitizer.
Dec 18 2018, 7:32 AM · Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

I don't completely follow logic behind cur_thread/cur_thread_fast/cur_thread1 and how it does not introduce slowdown.
cur_thread_fast still includes an indirection, so it looks exactly the same as the first version.
cur_thread_fast does not check for NULL, so I would expect it to be used only in few carefully chosen functions. But it's used in most entry functions. Which makes me wonder: when cur_thread_fast cannot be used if it can be used in all these places?
It seems that you use cur_thread only to lazily initialize cur_thread1 in Initialize or ThreadStart. But then the question is: why don't we explicitly intialize cur_thread1 in these functions, and then just have a single cur_thread function as before with no 2 subtly different accessors?

Dec 18 2018, 7:26 AM · Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

Can't agree with this. Only fiber is visible to user. Of cause, it is the same as thread until user switches it.

Dec 18 2018, 7:22 AM · Restricted Project
dvyukov added inline comments to D54889: Fiber support for thread sanitizer.
Dec 18 2018, 7:18 AM · Restricted Project

Dec 12 2018

dvyukov added a comment to D54889: Fiber support for thread sanitizer.

Lingfeng, thanks for extensive feedback.

This should allow that logic to work for QEMU at least, and it feels like it should work for all possible other uses (?)

I am not sure there are no programs that use setjmp/longjmp to switch fibers across threads. Yes, man says behavior is undefined. But strictly saying, longjmp shouldn't be used for fiber switching too (it's solely for jumping upwards on the same stack). So I feel people are just relying on implementation details here (let's test it, works, ok, let's use it).

You said that QEMU uses sigsetjmp/siglongjmp for coroutine switches. How does a coroutine always stay on the same thread then? Say, if they have a thread pool servicing all coroutines, I would expect that coroutines are randomly intermixed across threads. So it can happen that we setjmp on one thread, but then reschedule the coroutine with longjmp on another thread.

Thanks for pointing that out. I have to check more closely, but I haven't observed migration of fibers across physical threads at all in qemu. The tendency is to both create and switch the coroutine on a dedicated thread. Swapcontext is done to a trampoline function, to which one can return again later on. Kind of like a fiber pool, where reuse of a fiber means longjmping to the trampoline instead of another swapcontext.

I don't think there is a thread pool that mixes around the fibers. I guess this means we would have to annotate in the more general use case, but for QEMU, if we make the assumption that setjmp/longjmp follow the spec, while only allowing for physical thread switches in swapcontext, we should be OK (And physical thread switching in swapcontext is somethign QEMU does not do).

Dec 12 2018, 2:54 AM · Restricted Project

Dec 11 2018

dvyukov added inline comments to D54889: Fiber support for thread sanitizer.
Dec 11 2018, 6:28 AM · Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

Thinking of how we can eliminate the indirection in cur_thread...

Dec 11 2018, 6:10 AM · Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.
Dec 11 2018, 5:17 AM · Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.
  1. This introduces slowdown into the hottest runtime functions (branch and indirection in cur_thread). I think check_analyze.sh test will fail. Kinda hard to say, because it's broken already at the moment, but this perturbs runtime functions enough:

I have checked parts of the patch separately and found:

  • Part of patch related to HACKY_CALL does not affect code of critical functions and benchmark results
  • Part of patch related to proc() does not affect code of critical functions and benchmark results
  • The only part that affects critical functions is implementation cur_thread(). I tried to minimize its effect in new version of a patch.
Dec 11 2018, 5:02 AM · Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

Hi Dmitry,
I will try to answer your questions

  1. Do we want to synchronize fibers on switch? If fibers use TLS data, or cooperative scheduling (e.g. mutex unlock directly schedules the next critical section owner), or pass some data from prev fiber to next fiber, in all these cases not synchronizing fibers on switch will lead to false positives. As far as I remember in my old experiments I concluded that it's almost impossible to get rid of false positives it tasks/fibers are not synchronized on switch.

In case of single-threaded scheduler, it is worth to synchronize fibers on each switch. Currently I do it in client code using _tsan_release()/_tsan_acquire(), but it is possible to add flag for _tsan_switch_to_fiber() that will do it.

In case of multithreaded scheduler, client probably has own sychronization primitives (for example, custom mutex), and it is client's responsibility to call corresponding TSAN functions.

Dec 11 2018, 4:40 AM · Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

Lingfeng, thanks for extensive feedback.

Dec 11 2018, 4:31 AM · Restricted Project

Dec 10 2018

dvyukov added a comment to D54889: Fiber support for thread sanitizer.

FTR, Lingfeng did prototype change to qemu that uses these annotations:
https://android-review.googlesource.com/c/platform/external/qemu/+/844675

Dec 10 2018, 8:18 AM · Restricted Project
dvyukov added inline comments to D54889: Fiber support for thread sanitizer.
Dec 10 2018, 5:05 AM · Restricted Project

Dec 3 2018

dvyukov added inline comments to D54889: Fiber support for thread sanitizer.
Dec 3 2018, 8:24 AM · Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

Some high-level comments:

  1. Do we want to synchronize fibers on switch? If fibers use TLS data, or cooperative scheduling (e.g. mutex unlock directly schedules the next critical section owner), or pass some data from prev fiber to next fiber, in all these cases not synchronizing fibers on switch will lead to false positives. As far as I remember in my old experiments I concluded that it's almost impossible to get rid of false positives it tasks/fibers are not synchronized on switch.
Dec 3 2018, 8:17 AM · Restricted Project
dvyukov accepted D55119: [KMSAN] Enable -msan-handle-asm-conservative by default.

As per offline discussion: none of these tests test something that was used in user-space. So it does not make sense forking them for userspace/kernel.

Dec 3 2018, 12:56 AM

Nov 30 2018

dvyukov accepted D55119: [KMSAN] Enable -msan-handle-asm-conservative by default.
Nov 30 2018, 4:36 AM

Nov 29 2018

dvyukov accepted D55075: [TSan] Remove ignore_interceptors_accesses flag.
Nov 29 2018, 1:25 PM · Restricted Project

Nov 27 2018

dvyukov added a comment to D54889: Fiber support for thread sanitizer.

I think single threaded programs would also benefit from swapcontext support. At the very least it will give correct stacks. I think tsan shadow stack can also overflow on some fibers patterns (if a fiber has uneven number of function entries and exits).

Nov 27 2018, 6:56 AM · Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

It's unclear how this is supposed to be used. I would expect to see an interceptor for swapcontext that will make use of this, but there is none...

Interceptor for swapcontext without additional sanitizer API is not enough because it is not known when context is created and destroyed. Actually, I am not sure if swapcontext is actually used by someone because it is slow and has strange limitations.

My interface assumes is that users should call __tsan_switch_to_fiber() immediately before switching context and then call swapcontext or whatever he want to perform actual switch.

Nov 27 2018, 5:36 AM · Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

I'd like to make sure that the work can be re-used to implement proper understanding of Darwin GCD queues.

Nov 27 2018, 4:35 AM · Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

It's unclear how this is supposed to be used. I would expect to see an interceptor for swapcontext that will make use of this, but there is none...
If these annotations are supposed to be user callable (are they? why?), we also need interface declarations in:
https://github.com/llvm-mirror/compiler-rt/blob/master/include/sanitizer/tsan_interface.h
We also need tests (lots) that demonstrate how this can be used and that this works.

Nov 27 2018, 4:31 AM · Restricted Project

Nov 26 2018

dvyukov added a comment to D54835: tsan: Support calling ThreadCreate()/ThreadStart()/ThreadFinish() for non-current thread.

Fibers support sounds great.
Regardless of how we proceed with submitting patches, I would like to see the whole change first. Otherwise it's hard to see reasoning behind individual changes and understand if it's right approach or not.
Please upload whole change into a separate review.

Hi Dmitry,
I have uploaded full code in https://reviews.llvm.org/D54889

Nov 26 2018, 2:15 AM · Restricted Project

Nov 23 2018

dvyukov added a comment to D54835: tsan: Support calling ThreadCreate()/ThreadStart()/ThreadFinish() for non-current thread.

I have working implemented of fibers (coroutines) support for thread sanitizer.
Taking in the account that fibers are supported by address sanitizer, support in thread sanitizer may be useful as well.

This is a first patch of the changeset. Please advise, what is the preferred process of reviewing in such cases: submit patches one-by-one or submit the entire changeset?

Nov 23 2018, 12:34 AM · Restricted Project

Nov 21 2018

dvyukov committed rL347383: tsan: add pthread_tryjoin_np and pthread_timedjoin_np interceptors.
tsan: add pthread_tryjoin_np and pthread_timedjoin_np interceptors
Nov 21 2018, 1:35 AM
dvyukov committed rCRT347383: tsan: add pthread_tryjoin_np and pthread_timedjoin_np interceptors.
tsan: add pthread_tryjoin_np and pthread_timedjoin_np interceptors
Nov 21 2018, 1:34 AM
dvyukov closed D54521: tsan: Add pthread_tryjoin_np and pthread_timedjoin_np interceptors.

Committed in r347383
http://llvm.org/viewvc/llvm-project?view=revision&revision=347383

Nov 21 2018, 1:34 AM · Restricted Project
dvyukov accepted D54521: tsan: Add pthread_tryjoin_np and pthread_timedjoin_np interceptors.

Do you want me to merge this or you have commit access?

Nov 21 2018, 1:21 AM · Restricted Project
dvyukov added inline comments to D54521: tsan: Add pthread_tryjoin_np and pthread_timedjoin_np interceptors.
Nov 21 2018, 1:17 AM · Restricted Project

Nov 20 2018

dvyukov added inline comments to D54521: tsan: Add pthread_tryjoin_np and pthread_timedjoin_np interceptors.
Nov 20 2018, 8:39 PM · Restricted Project

Nov 19 2018

dvyukov accepted D54664: [tsan] Add __cxa_guard_acquire hooks to support cooperative scheduling.
Nov 19 2018, 10:23 PM

Nov 17 2018

dvyukov added inline comments to D54664: [tsan] Add __cxa_guard_acquire hooks to support cooperative scheduling.
Nov 17 2018, 9:29 AM
dvyukov added inline comments to D54664: [tsan] Add __cxa_guard_acquire hooks to support cooperative scheduling.
Nov 17 2018, 9:28 AM

Nov 15 2018

dvyukov added inline comments to D54521: tsan: Add pthread_tryjoin_np and pthread_timedjoin_np interceptors.
Nov 15 2018, 9:45 AM · Restricted Project
dvyukov added a comment to D54521: tsan: Add pthread_tryjoin_np and pthread_timedjoin_np interceptors.

We need tests for these functions in compiler-rt/test/tsan/

Nov 15 2018, 9:39 AM · Restricted Project

Oct 31 2018

dvyukov added inline comments to D53789: [hwasan] optionally right-align heap allocations.
Oct 31 2018, 1:15 AM

Oct 29 2018

dvyukov added inline comments to D53789: [hwasan] optionally right-align heap allocations.
Oct 29 2018, 1:39 PM
dvyukov added a comment to D53811: [MSan] another take at instrumenting inline assembly - now with calls.

LGTM

Oct 29 2018, 7:42 AM
dvyukov added a comment to D53811: [MSan] another take at instrumenting inline assembly - now with calls.

Otherwise looks good to me.

Oct 29 2018, 6:42 AM
dvyukov added a comment to D53171: [tsan] Bring Dispatch support to Linux.

Is it possible to make it just part of tsan without introducing a separate static library? That would be more scalable and easier to use.

We already doing something similar in tsan_interceptors.cc. For example, we intercept some libc++ functions, but end user may not link in libc++ and it will all work because interceptors do dynamic dispatch and don't fail if a function is not resolved.
This would require calling all dispatch functions as REAL(dispatch_foo), but otherwise should work.

The real problem here is -fblocks, which needs -lBlocksRuntime, and this dependency is implicitly generated by the compiler and I don't think there's a way to make it a weak dependency. I also don't want to rewrite this file to not use blocks as that's going to make everything much less readable. I'm open to suggestions, of course.

Don't we already have a separate clang_rt.tsan_cxx static library? I thought that's here specifically to break up the dependencies.

Oct 29 2018, 4:50 AM · Restricted Project

Oct 27 2018

dvyukov added inline comments to D53789: [hwasan] optionally right-align heap allocations.
Oct 27 2018, 1:19 AM

Oct 12 2018

dvyukov added inline comments to D53171: [tsan] Bring Dispatch support to Linux.
Oct 12 2018, 3:20 AM · Restricted Project
dvyukov added a comment to D53171: [tsan] Bring Dispatch support to Linux.

Is it possible to make it just part of tsan without introducing a separate static library? That would be more scalable and easier to use.

Oct 12 2018, 3:19 AM · Restricted Project

Sep 18 2018

dvyukov accepted D52167: [compiler-rt][TSan] Add TSan runtime support for Go on linux-aarch64..

Looks good to me

Sep 18 2018, 7:53 AM

Sep 17 2018

dvyukov added inline comments to D52167: [compiler-rt][TSan] Add TSan runtime support for Go on linux-aarch64..
Sep 17 2018, 6:45 AM
dvyukov added a comment to D52167: [compiler-rt][TSan] Add TSan runtime support for Go on linux-aarch64..

Hi Fangming,

Sep 17 2018, 6:38 AM

Aug 17 2018

dvyukov accepted D50920: [tsan] Avoid calling Block_copy in the "sync" GCD interceptors.
Aug 17 2018, 2:34 PM · Restricted Project
dvyukov accepted D50910: [sanitizer] Use private futex operations for BlockingMutex.
Aug 17 2018, 11:00 AM

Aug 13 2018

dvyukov added inline comments to D50549: [libcxx] [test] Repair thread unsafety in thread tests.
Aug 13 2018, 4:41 PM
dvyukov added inline comments to D50549: [libcxx] [test] Repair thread unsafety in thread tests.
Aug 13 2018, 10:26 AM
dvyukov added inline comments to D50549: [libcxx] [test] Repair thread unsafety in thread tests.
Aug 13 2018, 10:07 AM
dvyukov added inline comments to D50549: [libcxx] [test] Repair thread unsafety in thread tests.
Aug 13 2018, 9:56 AM

Jul 26 2018

dvyukov committed rL338023: [tsan] Fix gcc pedantic warning.
[tsan] Fix gcc pedantic warning
Jul 26 2018, 6:03 AM
dvyukov committed rCRT338023: [tsan] Fix gcc pedantic warning.
[tsan] Fix gcc pedantic warning
Jul 26 2018, 6:03 AM
dvyukov closed D49817: [tsan] Fix gcc pedantic warning.

Sure. Merged as 338023. Thanks.

Jul 26 2018, 6:03 AM

Jul 25 2018

dvyukov accepted D49817: [tsan] Fix gcc pedantic warning.
Jul 25 2018, 10:56 PM

Jul 24 2018

dvyukov accepted D49707: [tsan] Fix crash in objc_sync_enter/objc_sync_exit when using an Obj-C tagged pointer.
Jul 24 2018, 12:49 AM · Restricted Project

Jul 20 2018

dvyukov committed rCRT337550: esan: fix shadow setup.
esan: fix shadow setup
Jul 20 2018, 6:45 AM
dvyukov committed rL337550: esan: fix shadow setup.
esan: fix shadow setup
Jul 20 2018, 6:45 AM
dvyukov closed D49367: sanitizers: consistently check result of MmapFixedNoReserve.

Submitted in 337531

Jul 20 2018, 1:40 AM
dvyukov added inline comments to D49367: sanitizers: consistently check result of MmapFixedNoReserve.
Jul 20 2018, 1:40 AM
dvyukov committed rCRT337531: sanitizers: consistently check result of MmapFixedNoReserve.
sanitizers: consistently check result of MmapFixedNoReserve
Jul 20 2018, 1:39 AM
dvyukov committed rL337531: sanitizers: consistently check result of MmapFixedNoReserve.
sanitizers: consistently check result of MmapFixedNoReserve
Jul 20 2018, 1:38 AM

Jul 16 2018

dvyukov created D49367: sanitizers: consistently check result of MmapFixedNoReserve.
Jul 16 2018, 2:56 AM

Jun 22 2018

dvyukov committed rCRT335322: tsan: fix deficiency in MutexReadOrWriteUnlock.
tsan: fix deficiency in MutexReadOrWriteUnlock
Jun 22 2018, 1:32 AM
dvyukov committed rL335322: tsan: fix deficiency in MutexReadOrWriteUnlock.
tsan: fix deficiency in MutexReadOrWriteUnlock
Jun 22 2018, 1:32 AM

Jun 14 2018

dvyukov added a comment to D32915: [msan] Fix PR32842.

Nice!

Jun 14 2018, 10:40 PM · Restricted Project

Jun 13 2018

dvyukov accepted D48097: [TSan] Fix madvise(MADV_NOHUGEPAGE) for meta shadow memory.
Jun 13 2018, 8:03 AM

Jun 12 2018

dvyukov added inline comments to D48097: [TSan] Fix madvise(MADV_NOHUGEPAGE) for meta shadow memory.
Jun 12 2018, 10:50 PM

Jun 9 2018

dvyukov added a comment to D47977: [Fuzzer] First step to thread affinity.

And we did not even get to windows, mac, fuchsia and akaros.

Jun 9 2018, 3:33 AM
dvyukov added a comment to D47977: [Fuzzer] First step to thread affinity.

Well on Linux you can check process infos on /proc/<proc>/status I believe but that might be overkill.

Jun 9 2018, 3:30 AM
dvyukov added a comment to D47977: [Fuzzer] First step to thread affinity.

True ideally what I tried to say in the description is ideally the cpu load ought to be checked first but that s a lot of code :-)

Jun 9 2018, 3:18 AM
dvyukov added a comment to D47977: [Fuzzer] First step to thread affinity.

I understand your points, but usually see the jobs are often bound to cpu0 while this cpu can be potentially pretty busy.

Jun 9 2018, 2:54 AM
dvyukov added a comment to D47977: [Fuzzer] First step to thread affinity.

What's the gain? Performance improvement? What are the numbers for benchmarking?

Jun 9 2018, 2:36 AM

Jun 7 2018

dvyukov accepted D47289: [scudo] Improve the scalability of the shared TSD model.

So your current version is actually the best one.
Thanks for bearing with me.

Jun 7 2018, 10:47 PM