summaryrefslogtreecommitdiffstats
path: root/clang-tools-extra/clang-tidy/google/MemsetZeroLengthCheck.h
diff options
context:
space:
mode:
authorDmitry Vyukov <dvyukov@google.com>2017-07-14 11:30:06 +0000
committerDmitry Vyukov <dvyukov@google.com>2017-07-14 11:30:06 +0000
commit9f2c6207d5f925037ea776ddc2671d9c5d39ca8d (patch)
tree562f74eeef4ad70becec5daeafbf2dcc46fcd444 /clang-tools-extra/clang-tidy/google/MemsetZeroLengthCheck.h
parent0e03935182a331bf08a5bdfcfc2755b775605bc1 (diff)
downloadbcm5719-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
OpenPOWER on IntegriCloud