This is an archive of the discontinued LLVM Phabricator instance.

[XRay][compiler-rt] Use sanitizer_common's atomic ops
ClosedPublic

Authored by dberris on Mar 26 2017, 10:03 PM.

Details

Reviewers
dblaikie
pelikan
Summary

Instead of std::atomic APIs for atomic operations, we instead use APIs
include with sanitizer_common. This allows us to, at runtime, not have
to depend on potentially dynamically provided implementations of these
atomic operations.

Currently only do this for x86_64.

Fixes http://llvm.org/PR32274.

Event Timeline

dberris created this revision.Mar 26 2017, 10:03 PM
dberris updated this revision to Diff 93098.Mar 26 2017, 10:11 PM
dberris retitled this revision from split to [XRay][compiler-rt] Use sanitizer_common's atomic ops.
dberris edited the summary of this revision. (Show Details)

Retitle.

pelikan edited edge metadata.Mar 26 2017, 11:48 PM

Overall, I like it. Except for burning CPU while waiting on someone else's write(2) to (potentially) spinning rust.

lib/xray/xray_buffer_queue.h
44

This lock is being held over all Buffers (which may not be that bad actually). It is also held during the only use of apply(), which calls retryingWriteAll() and therefore will take a lot of time, including passively waiting on system calls. It would therefore make sense to use the blocking mutex here, to avoid burning CPU for potentially milliseconds.

Is there any downside to a blocking lock in this scenario? The other ones look fine as the locks only protect very small regions of memory.

dberris updated this revision to Diff 93099.Mar 27 2017, 12:16 AM
dberris marked an inline comment as done.
  • fixup: use a blocking mutex in the buffer queue
lib/xray/xray_buffer_queue.h
44

For the usage patterns we have, this should not be much of a problem. Let me explain why:

  • We expect that getting buffers and returning buffers to happen more frequently than we do calling apply(...). That should be fairly quick.
  • The caller to apply usually is a thread that has already ensured that all threads that want to write into the buffers will have returned the buffers already. While this is an implementation detail at a higher level (in the FDR logging implementation), we kind-of know it from here.

In the review thread for this original change, we decided to not hand-write our own spinlock, but it's more apt for the get and release cases. I'm fine using an explicitly blocking mutex here, but that means we're trading off the potential chance of spinning for a while (fairly low based on the way we're using this data structure) on some threads, with the potential that when we're doing FDR mode that we're blocking threads.

It's easy enough to switch anyway, so I've changed it to use a blocking mutex.

pelikan accepted this revision.Mar 27 2017, 12:21 AM
This revision is now accepted and ready to land.Mar 27 2017, 12:21 AM
dberris closed this revision.Mar 27 2017, 12:45 AM

Submitted as rL298833.