[PATCH] D54684: [XRay] Move buffer extents back to the heap

Dean Michael Berris via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun Nov 18 21:33:11 PST 2018


dberris created this revision.
dberris added a reviewer: mboerger.
Herald added a subscriber: jfb.

This change addresses an issue which shows up with the synchronised race
between threads writing into a buffer, and another thread reading the
buffer.

In a lot of cases, we cannot guarantee that threads will always see the
signal to finalise their buffers in time despite the grace periods and
state machine maintained through atomic variables. This change addresses
it by ensuring that the same instance being updated to indicate how much
of the buffer is "used" by the writing thread is the same instance being
read by the thread processing the buffer to be written out to disk or
handled through the iterators.

To do this, we ensure that all the "extents" instances live in their own
the backing store, in a different contiguous page from the
buffer-specific backing store. We also take precautions to ensure that
the atomic variables are cache-line-sized to prevent false-sharing from
unnecessarily causing cache contention on unrelated writes/reads.

It's feasible that we may in the future be able to move the storage of
the extents objects into the single backing store, slightly changing the
way to compute the size(s) of the buffers, but in the meantime we'll
settle for the isolation afforded by having a different backing store
for the extents instances.


Repository:
  rL LLVM

https://reviews.llvm.org/D54684

Files:
  compiler-rt/lib/xray/tests/unit/test_helpers.cc
  compiler-rt/lib/xray/xray_buffer_queue.cc
  compiler-rt/lib/xray/xray_buffer_queue.h
  compiler-rt/lib/xray/xray_fdr_controller.h
  compiler-rt/lib/xray/xray_fdr_log_writer.h
  compiler-rt/lib/xray/xray_fdr_logging.cc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D54684.174558.patch
Type: text/x-patch
Size: 16238 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20181119/37130f82/attachment.bin>


More information about the llvm-commits mailing list