diff options
| author | Dmitry Vyukov <dvyukov@google.com> | 2017-07-14 11:30:06 +0000 |
|---|---|---|
| committer | Dmitry Vyukov <dvyukov@google.com> | 2017-07-14 11:30:06 +0000 |
| commit | 9f2c6207d5f925037ea776ddc2671d9c5d39ca8d (patch) | |
| tree | 562f74eeef4ad70becec5daeafbf2dcc46fcd444 /clang-tools-extra/clang-tidy/google/MemsetZeroLengthCheck.h | |
| parent | 0e03935182a331bf08a5bdfcfc2755b775605bc1 (diff) | |
| download | bcm5719-llvm-9f2c6207d5f925037ea776ddc2671d9c5d39ca8d.tar.gz bcm5719-llvm-9f2c6207d5f925037ea776ddc2671d9c5d39ca8d.zip | |
tsan: optimize sync clock memory consumption
This change implements 2 optimizations of sync clocks that reduce memory consumption:
Use previously unused first level block space to store clock elements.
Currently a clock for 100 threads consumes 3 512-byte blocks:
2 64-bit second level blocks to store clock elements
+1 32-bit first level block to store indices to second level blocks
Only 8 bytes of the first level block are actually used.
With this change such clock consumes only 2 blocks.
Share similar clocks differing only by a single clock entry for the current thread.
When a thread does several release operations on fresh sync objects without intervening
acquire operations in between (e.g. initialization of several fields in ctor),
the resulting clocks differ only by a single entry for the current thread.
This change reuses a single clock for such release operations. The current thread time
(which is different for different clocks) is stored in dirty entries.
We are experiencing issues with a large program that eats all 64M clock blocks
(32GB of non-flushable memory) and crashes with dense allocator overflow.
Max number of threads in the program is ~170 which is currently quite unfortunate
(consume 4 blocks per clock). Currently it crashes after consuming 60+ GB of memory.
The first optimization brings clock block consumption down to ~40M and
allows the program to work. The second optimization further reduces block consumption
to "modest" 16M blocks (~8GB of RAM) and reduces overall RAM consumption to ~30GB.
Measurements on another real world C++ RPC benchmark show RSS reduction
from 3.491G to 3.186G and a modest speedup of ~5%.
Go parallel client/server HTTP benchmark:
https://github.com/golang/benchmarks/blob/master/http/http.go
shows RSS reduction from 320MB to 240MB and a few percent speedup.
Reviewed in https://reviews.llvm.org/D35323
llvm-svn: 308018
Diffstat (limited to 'clang-tools-extra/clang-tidy/google/MemsetZeroLengthCheck.h')
0 files changed, 0 insertions, 0 deletions

