On Fri, 26 May 2023 at 12:06, Ondřej Surý <ond...@sury.org> wrote: > > > > On 26. 5. 2023, at 8:08, Dmitry Vyukov <dvyu...@google.com> wrote: > > > > On Fri, 26 May 2023 at 07:33, Ondřej Surý <ond...@sury.org> wrote: > >> > >> A little bit related question/problem - some of our system test jobs got > >> significantly slower (3x-5x) with **clang-16** TSAN after we integrated > >> liburcu to BIND 9. The GCC (13.1.1) TSAN doesn’t exhibit this behavior. > >> > >> The liburcu integration in BIND 9 is very light at the moment - we use > >> liburcu for qptrie and there’s some usage of wfcqueue for queuing > >> jobs(callbacks) between threads. > >> > >> We were not able to put a finger on it yet, but saying this aloud might > >> help diagnose this. > > > > Interesting. Clang 16 got a completely new tsan runtime > > implementation, which is generally ~2x faster and consumes less > > memory. > > However, of course, it's not possible to optimize for all gazillion of > > programs in the world. I suspect librcu tests are quite extreme in > > terms of synchronization. > > > > If you collect perf profiles for both, I can look for some low hanging > > fruit. > > Or is there a reasonable way for me to reproduce? > > Looks like it got all resolved by using the latest liburcu patch set with full > TSAN support. I haven't realized that our CI still runs with whatever liburcu > Debian bullseye have. Sorry for the confusion. > > And I can no longer reproduce this locally. > > FTR here are some numbers from my local system (13th Gen Intel(R) Core(TM) > i9-13900K) > running TSAN-enabled patched userspace-rcu[1], libuv 1.45.0 and OpenSSL 3.0.8: > > gcc-13 baseline > > rpz: passed in 198.71s (0:03:18) > rpzrecurse: passed in 310.62s (0:05:10) > rrsetorder: passed in 200.40s (0:03:20) > > gcc-13 TSAN > > rpz: passed in 305.64s (0:05:05) > rpzrecurse: passed in 427.73s (0:07:07) > rrsetorder: passed in 260.65s (0:04:20) > > clang-16 TSAN > > rpz: passed in 290.05s (0:04:50) > rpzrecurse: passed in 468.53s (0:07:48) > rrsetorder: passed in 258.97s (0:04:18) > > This looks quite reasonable to me. > > 1. git fetch https://review.lttng.org/userspace-rcu refs/changes/58/10058/1 > && git checkout FETCH_HEAD
Yes, looks reasonable. _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
