2019-08-01 20:30:58 +08:00
|
|
|
//===-- xray_fdr_logging.cpp -----------------------------------*- C++ -*-===//
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
[XRay] [compiler-rt] Refactor logic for xray fdr logging. NFC.
Summary:
Separated the IO and the thread local storage state machine of logging
from the writing of log records once the contents are deterministic.
Finer granularity functions are provided as inline functions in the same
header such that stack does not grow due to the functions being separated.
An executable utility xray_fdr_log_printer is also implemented to use the
finest granularity functions to produce binary test data in the FDR format
with a relatively convenient text input.
For example, one can take a file with textual contents layed out in rows
and feed it to the binary to generate data that llvm-xray convert can then
read. This is a convenient way to build a test suite for llvm-xray convert
to ensure it's robust to the fdr format.
Example:
$cat myFile.txt
NewBuffer : { time = 2 , Tid=5}
NewCPU : { CPU =1 , TSC = 123}
Function : { FuncId = 5, TSCDelta = 3, EntryType = Entry }
Function : { FuncId = 5, TSCDelta = 5, EntryType = Exit}
TSCWrap : { TSC = 678 }
Function : { FuncId = 6, TSCDelta = 0, EntryType = Entry }
Function : { FuncId = 6, TSCDelta = 50, EntryType = Exit }
EOB : { }
$cat myFile.txt | ./bin/xray_fdr_log_printer > /tmp/binarydata.bin
$./bin/llvm-xray convert -output-format=yaml -output=- /tmp/binarydata.bin
yaml format comes out as expected.
Reviewers: dberris, pelikan
Reviewed By: dberris
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D30850
llvm-svn: 297801
2017-03-15 11:12:01 +08:00
|
|
|
// This file is a part of XRay, a dynamic runtime instrumentation system.
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
//
|
|
|
|
// Here we implement the Flight Data Recorder mode for XRay, where we use
|
|
|
|
// compact structures to store records in memory as well as when writing out the
|
|
|
|
// data to files.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
#include "xray_fdr_logging.h"
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
#include <cassert>
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
#include <errno.h>
|
2018-06-05 16:20:54 +08:00
|
|
|
#include <limits>
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
#include <memory>
|
2018-07-18 09:31:30 +08:00
|
|
|
#include <pthread.h>
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
#include <sys/time.h>
|
|
|
|
#include <time.h>
|
|
|
|
#include <unistd.h>
|
|
|
|
|
2018-06-05 18:12:58 +08:00
|
|
|
#include "sanitizer_common/sanitizer_allocator_internal.h"
|
2017-03-27 15:13:35 +08:00
|
|
|
#include "sanitizer_common/sanitizer_atomic.h"
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
#include "sanitizer_common/sanitizer_common.h"
|
|
|
|
#include "xray/xray_interface.h"
|
|
|
|
#include "xray/xray_records.h"
|
2018-09-17 11:09:01 +08:00
|
|
|
#include "xray_allocator.h"
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
#include "xray_buffer_queue.h"
|
|
|
|
#include "xray_defs.h"
|
2018-10-30 12:35:48 +08:00
|
|
|
#include "xray_fdr_controller.h"
|
2018-05-04 14:13:35 +08:00
|
|
|
#include "xray_fdr_flags.h"
|
2018-09-20 13:22:37 +08:00
|
|
|
#include "xray_fdr_log_writer.h"
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
#include "xray_flags.h"
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
#include "xray_recursion_guard.h"
|
2017-02-11 04:30:43 +08:00
|
|
|
#include "xray_tsc.h"
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
#include "xray_utils.h"
|
|
|
|
|
|
|
|
namespace __xray {
|
|
|
|
|
2018-09-28 10:05:52 +08:00
|
|
|
static atomic_sint32_t LoggingStatus = {
|
|
|
|
XRayLogInitStatus::XRAY_LOG_UNINITIALIZED};
|
2018-06-05 16:20:54 +08:00
|
|
|
|
2018-09-28 10:05:52 +08:00
|
|
|
namespace {
|
2018-11-07 12:37:42 +08:00
|
|
|
|
2018-06-05 16:20:54 +08:00
|
|
|
// Group together thread-local-data in a struct, then hide it behind a function
|
|
|
|
// call so that it can be initialized on first use instead of as a global. We
|
|
|
|
// force the alignment to 64-bytes for x86 cache line alignment, as this
|
|
|
|
// structure is used in the hot path of implementation.
|
2018-12-23 23:09:20 +08:00
|
|
|
struct XRAY_TLS_ALIGNAS(64) ThreadLocalData {
|
2018-09-17 11:09:01 +08:00
|
|
|
BufferQueue::Buffer Buffer{};
|
2018-10-30 12:35:48 +08:00
|
|
|
BufferQueue *BQ = nullptr;
|
2018-06-05 16:20:54 +08:00
|
|
|
|
2018-10-30 12:35:48 +08:00
|
|
|
using LogWriterStorage =
|
|
|
|
typename std::aligned_storage<sizeof(FDRLogWriter),
|
|
|
|
alignof(FDRLogWriter)>::type;
|
2018-06-05 16:20:54 +08:00
|
|
|
|
2018-10-30 12:35:48 +08:00
|
|
|
LogWriterStorage LWStorage;
|
|
|
|
FDRLogWriter *Writer = nullptr;
|
|
|
|
|
|
|
|
using ControllerStorage =
|
|
|
|
typename std::aligned_storage<sizeof(FDRController<>),
|
|
|
|
alignof(FDRController<>)>::type;
|
|
|
|
ControllerStorage CStorage;
|
|
|
|
FDRController<> *Controller = nullptr;
|
2018-06-05 16:20:54 +08:00
|
|
|
};
|
2018-10-30 12:35:48 +08:00
|
|
|
|
2018-09-28 10:05:52 +08:00
|
|
|
} // namespace
|
2018-06-05 16:20:54 +08:00
|
|
|
|
|
|
|
static_assert(std::is_trivially_destructible<ThreadLocalData>::value,
|
|
|
|
"ThreadLocalData must be trivially destructible");
|
|
|
|
|
|
|
|
// Use a global pthread key to identify thread-local data for logging.
|
|
|
|
static pthread_key_t Key;
|
|
|
|
|
2018-07-18 09:31:30 +08:00
|
|
|
// Global BufferQueue.
|
2018-09-17 11:09:01 +08:00
|
|
|
static std::aligned_storage<sizeof(BufferQueue)>::type BufferQueueStorage;
|
2018-07-18 09:31:30 +08:00
|
|
|
static BufferQueue *BQ = nullptr;
|
|
|
|
|
2018-10-30 12:35:48 +08:00
|
|
|
// Global thresholds for function durations.
|
|
|
|
static atomic_uint64_t ThresholdTicks{0};
|
|
|
|
|
|
|
|
// Global for ticks per second.
|
|
|
|
static atomic_uint64_t TicksPerSec{0};
|
|
|
|
|
2018-07-18 09:31:30 +08:00
|
|
|
static atomic_sint32_t LogFlushStatus = {
|
|
|
|
XRayLogFlushStatus::XRAY_LOG_NOT_FLUSHING};
|
|
|
|
|
2018-06-05 16:20:54 +08:00
|
|
|
// This function will initialize the thread-local data structure used by the FDR
|
|
|
|
// logging implementation and return a reference to it. The implementation
|
|
|
|
// details require a bit of care to maintain.
|
|
|
|
//
|
|
|
|
// First, some requirements on the implementation in general:
|
|
|
|
//
|
|
|
|
// - XRay handlers should not call any memory allocation routines that may
|
|
|
|
// delegate to an instrumented implementation. This means functions like
|
|
|
|
// malloc() and free() should not be called while instrumenting.
|
|
|
|
//
|
|
|
|
// - We would like to use some thread-local data initialized on first-use of
|
|
|
|
// the XRay instrumentation. These allow us to implement unsynchronized
|
|
|
|
// routines that access resources associated with the thread.
|
|
|
|
//
|
|
|
|
// The implementation here uses a few mechanisms that allow us to provide both
|
|
|
|
// the requirements listed above. We do this by:
|
|
|
|
//
|
|
|
|
// 1. Using a thread-local aligned storage buffer for representing the
|
|
|
|
// ThreadLocalData struct. This data will be uninitialized memory by
|
|
|
|
// design.
|
|
|
|
//
|
|
|
|
// 2. Not requiring a thread exit handler/implementation, keeping the
|
|
|
|
// thread-local as purely a collection of references/data that do not
|
|
|
|
// require cleanup.
|
|
|
|
//
|
|
|
|
// We're doing this to avoid using a `thread_local` object that has a
|
|
|
|
// non-trivial destructor, because the C++ runtime might call std::malloc(...)
|
|
|
|
// to register calls to destructors. Deadlocks may arise when, for example, an
|
|
|
|
// externally provided malloc implementation is XRay instrumented, and
|
|
|
|
// initializing the thread-locals involves calling into malloc. A malloc
|
|
|
|
// implementation that does global synchronization might be holding a lock for a
|
|
|
|
// critical section, calling a function that might be XRay instrumented (and
|
|
|
|
// thus in turn calling into malloc by virtue of registration of the
|
|
|
|
// thread_local's destructor).
|
2018-12-23 23:09:20 +08:00
|
|
|
#if XRAY_HAS_TLS_ALIGNAS
|
2018-07-18 09:31:30 +08:00
|
|
|
static_assert(alignof(ThreadLocalData) >= 64,
|
|
|
|
"ThreadLocalData must be cache line aligned.");
|
2018-12-23 23:09:20 +08:00
|
|
|
#endif
|
2018-06-05 16:20:54 +08:00
|
|
|
static ThreadLocalData &getThreadLocalData() {
|
2018-07-18 09:31:30 +08:00
|
|
|
thread_local typename std::aligned_storage<
|
|
|
|
sizeof(ThreadLocalData), alignof(ThreadLocalData)>::type TLDStorage{};
|
|
|
|
|
|
|
|
if (pthread_getspecific(Key) == NULL) {
|
|
|
|
new (reinterpret_cast<ThreadLocalData *>(&TLDStorage)) ThreadLocalData{};
|
|
|
|
pthread_setspecific(Key, &TLDStorage);
|
|
|
|
}
|
|
|
|
|
|
|
|
return *reinterpret_cast<ThreadLocalData *>(&TLDStorage);
|
2018-06-05 16:20:54 +08:00
|
|
|
}
|
|
|
|
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
static XRayFileHeader &fdrCommonHeaderInfo() {
|
|
|
|
static std::aligned_storage<sizeof(XRayFileHeader)>::type HStorage;
|
|
|
|
static pthread_once_t OnceInit = PTHREAD_ONCE_INIT;
|
|
|
|
static bool TSCSupported = true;
|
|
|
|
static uint64_t CycleFrequency = NanosecondsPerSecond;
|
2018-11-07 12:37:42 +08:00
|
|
|
pthread_once(
|
|
|
|
&OnceInit, +[] {
|
|
|
|
XRayFileHeader &H = reinterpret_cast<XRayFileHeader &>(HStorage);
|
|
|
|
// Version 2 of the log writes the extents of the buffer, instead of
|
|
|
|
// relying on an end-of-buffer record.
|
|
|
|
// Version 3 includes PID metadata record.
|
|
|
|
// Version 4 includes CPU data in the custom event records.
|
|
|
|
// Version 5 uses relative deltas for custom and typed event records,
|
|
|
|
// and removes the CPU data in custom event records (similar to how
|
|
|
|
// function records use deltas instead of full TSCs and rely on other
|
|
|
|
// metadata records for TSC wraparound and CPU migration).
|
|
|
|
H.Version = 5;
|
|
|
|
H.Type = FileTypes::FDR_LOG;
|
|
|
|
|
|
|
|
// Test for required CPU features and cache the cycle frequency
|
|
|
|
TSCSupported = probeRequiredCPUFeatures();
|
|
|
|
if (TSCSupported)
|
|
|
|
CycleFrequency = getTSCFrequency();
|
|
|
|
H.CycleFrequency = CycleFrequency;
|
|
|
|
|
|
|
|
// FIXME: Actually check whether we have 'constant_tsc' and
|
|
|
|
// 'nonstop_tsc' before setting the values in the header.
|
|
|
|
H.ConstantTSC = 1;
|
|
|
|
H.NonstopTSC = 1;
|
|
|
|
});
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
return reinterpret_cast<XRayFileHeader &>(HStorage);
|
2018-05-14 11:35:01 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// This is the iterator implementation, which knows how to handle FDR-mode
|
|
|
|
// specific buffers. This is used as an implementation of the iterator function
|
|
|
|
// needed by __xray_set_buffer_iterator(...). It maintains a global state of the
|
|
|
|
// buffer iteration for the currently installed FDR mode buffers. In particular:
|
|
|
|
//
|
|
|
|
// - If the argument represents the initial state of XRayBuffer ({nullptr, 0})
|
|
|
|
// then the iterator returns the header information.
|
|
|
|
// - If the argument represents the header information ({address of header
|
|
|
|
// info, size of the header info}) then it returns the first FDR buffer's
|
|
|
|
// address and extents.
|
|
|
|
// - It will keep returning the next buffer and extents as there are more
|
|
|
|
// buffers to process. When the input represents the last buffer, it will
|
|
|
|
// return the initial state to signal completion ({nullptr, 0}).
|
|
|
|
//
|
|
|
|
// See xray/xray_log_interface.h for more details on the requirements for the
|
|
|
|
// implementations of __xray_set_buffer_iterator(...) and
|
|
|
|
// __xray_log_process_buffers(...).
|
|
|
|
XRayBuffer fdrIterator(const XRayBuffer B) {
|
2018-05-14 12:14:39 +08:00
|
|
|
DCHECK(internal_strcmp(__xray_log_get_current_mode(), "xray-fdr") == 0);
|
2018-05-14 11:35:01 +08:00
|
|
|
DCHECK(BQ->finalizing());
|
|
|
|
|
|
|
|
if (BQ == nullptr || !BQ->finalizing()) {
|
|
|
|
if (Verbosity())
|
|
|
|
Report(
|
|
|
|
"XRay FDR: Failed global buffer queue is null or not finalizing!\n");
|
|
|
|
return {nullptr, 0};
|
|
|
|
}
|
|
|
|
|
|
|
|
// We use a global scratch-pad for the header information, which only gets
|
|
|
|
// initialized the first time this function is called. We'll update one part
|
|
|
|
// of this information with some relevant data (in particular the number of
|
|
|
|
// buffers to expect).
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
static std::aligned_storage<sizeof(XRayFileHeader)>::type HeaderStorage;
|
|
|
|
static pthread_once_t HeaderOnce = PTHREAD_ONCE_INIT;
|
2018-11-07 12:37:42 +08:00
|
|
|
pthread_once(
|
|
|
|
&HeaderOnce, +[] {
|
|
|
|
reinterpret_cast<XRayFileHeader &>(HeaderStorage) =
|
|
|
|
fdrCommonHeaderInfo();
|
|
|
|
});
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
|
|
|
|
// We use a convenience alias for code referring to Header from here on out.
|
|
|
|
auto &Header = reinterpret_cast<XRayFileHeader &>(HeaderStorage);
|
2018-05-14 11:35:01 +08:00
|
|
|
if (B.Data == nullptr && B.Size == 0) {
|
|
|
|
Header.FdrData = FdrAdditionalHeaderData{BQ->ConfiguredBufferSize()};
|
|
|
|
return XRayBuffer{static_cast<void *>(&Header), sizeof(Header)};
|
|
|
|
}
|
|
|
|
|
|
|
|
static BufferQueue::const_iterator It{};
|
|
|
|
static BufferQueue::const_iterator End{};
|
2018-09-22 00:34:42 +08:00
|
|
|
static uint8_t *CurrentBuffer{nullptr};
|
2018-09-17 11:09:01 +08:00
|
|
|
static size_t SerializedBufferSize = 0;
|
2018-05-14 11:35:01 +08:00
|
|
|
if (B.Data == static_cast<void *>(&Header) && B.Size == sizeof(Header)) {
|
|
|
|
// From this point on, we provide raw access to the raw buffer we're getting
|
|
|
|
// from the BufferQueue. We're relying on the iterators from the current
|
|
|
|
// Buffer queue.
|
|
|
|
It = BQ->cbegin();
|
|
|
|
End = BQ->cend();
|
|
|
|
}
|
|
|
|
|
2018-07-19 13:17:32 +08:00
|
|
|
if (CurrentBuffer != nullptr) {
|
2018-09-17 11:09:01 +08:00
|
|
|
deallocateBuffer(CurrentBuffer, SerializedBufferSize);
|
2018-07-19 13:17:32 +08:00
|
|
|
CurrentBuffer = nullptr;
|
|
|
|
}
|
|
|
|
|
2018-05-14 11:35:01 +08:00
|
|
|
if (It == End)
|
|
|
|
return {nullptr, 0};
|
|
|
|
|
2018-07-19 13:17:32 +08:00
|
|
|
// Set up the current buffer to contain the extents like we would when writing
|
|
|
|
// out to disk. The difference here would be that we still write "empty"
|
|
|
|
// buffers, or at least go through the iterators faithfully to let the
|
|
|
|
// handlers see the empty buffers in the queue.
|
2018-11-09 14:39:45 +08:00
|
|
|
//
|
|
|
|
// We need this atomic fence here to ensure that writes happening to the
|
|
|
|
// buffer have been committed before we load the extents atomically. Because
|
|
|
|
// the buffer is not explicitly synchronised across threads, we rely on the
|
|
|
|
// fence ordering to ensure that writes we expect to have been completed
|
|
|
|
// before the fence are fully committed before we read the extents.
|
|
|
|
atomic_thread_fence(memory_order_acquire);
|
2018-11-20 09:00:26 +08:00
|
|
|
auto BufferSize = atomic_load(It->Extents, memory_order_acquire);
|
2018-09-17 11:09:01 +08:00
|
|
|
SerializedBufferSize = BufferSize + sizeof(MetadataRecord);
|
|
|
|
CurrentBuffer = allocateBuffer(SerializedBufferSize);
|
2018-07-19 13:17:32 +08:00
|
|
|
if (CurrentBuffer == nullptr)
|
|
|
|
return {nullptr, 0};
|
|
|
|
|
|
|
|
// Write out the extents as a Metadata Record into the CurrentBuffer.
|
|
|
|
MetadataRecord ExtentsRecord;
|
|
|
|
ExtentsRecord.Type = uint8_t(RecordType::Metadata);
|
|
|
|
ExtentsRecord.RecordKind =
|
|
|
|
uint8_t(MetadataRecord::RecordKinds::BufferExtents);
|
|
|
|
internal_memcpy(ExtentsRecord.Data, &BufferSize, sizeof(BufferSize));
|
|
|
|
auto AfterExtents =
|
|
|
|
static_cast<char *>(internal_memcpy(CurrentBuffer, &ExtentsRecord,
|
|
|
|
sizeof(MetadataRecord))) +
|
|
|
|
sizeof(MetadataRecord);
|
|
|
|
internal_memcpy(AfterExtents, It->Data, BufferSize);
|
|
|
|
|
2018-05-14 11:55:12 +08:00
|
|
|
XRayBuffer Result;
|
2018-07-19 13:17:32 +08:00
|
|
|
Result.Data = CurrentBuffer;
|
|
|
|
Result.Size = SerializedBufferSize;
|
2018-05-14 11:35:01 +08:00
|
|
|
++It;
|
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
// Must finalize before flushing.
|
2017-02-08 07:35:34 +08:00
|
|
|
XRayLogFlushStatus fdrLoggingFlush() XRAY_NEVER_INSTRUMENT {
|
2018-06-05 14:12:42 +08:00
|
|
|
if (atomic_load(&LoggingStatus, memory_order_acquire) !=
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
XRayLogInitStatus::XRAY_LOG_FINALIZED) {
|
2018-06-05 14:12:42 +08:00
|
|
|
if (Verbosity())
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
Report("Not flushing log, implementation is not finalized.\n");
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
return XRayLogFlushStatus::XRAY_LOG_NOT_FLUSHING;
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
}
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
|
2017-03-27 15:13:35 +08:00
|
|
|
s32 Result = XRayLogFlushStatus::XRAY_LOG_NOT_FLUSHING;
|
2018-06-05 14:12:42 +08:00
|
|
|
if (!atomic_compare_exchange_strong(&LogFlushStatus, &Result,
|
|
|
|
XRayLogFlushStatus::XRAY_LOG_FLUSHING,
|
|
|
|
memory_order_release)) {
|
|
|
|
if (Verbosity())
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
Report("Not flushing log, implementation is still finalizing.\n");
|
2017-03-27 15:13:35 +08:00
|
|
|
return static_cast<XRayLogFlushStatus>(Result);
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
}
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
if (BQ == nullptr) {
|
2018-06-05 14:12:42 +08:00
|
|
|
if (Verbosity())
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
Report("Cannot flush when global buffer queue is null.\n");
|
|
|
|
return XRayLogFlushStatus::XRAY_LOG_NOT_FLUSHING;
|
|
|
|
}
|
|
|
|
|
2017-11-28 19:49:22 +08:00
|
|
|
// We wait a number of milliseconds to allow threads to see that we've
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
// finalised before attempting to flush the log.
|
2018-06-05 14:12:42 +08:00
|
|
|
SleepForMillis(fdrFlags()->grace_period_ms);
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
|
2018-05-14 11:35:01 +08:00
|
|
|
// At this point, we're going to uninstall the iterator implementation, before
|
|
|
|
// we decide to do anything further with the global buffer queue.
|
|
|
|
__xray_log_remove_buffer_iterator();
|
|
|
|
|
2018-07-18 09:31:30 +08:00
|
|
|
// Once flushed, we should set the global status of the logging implementation
|
|
|
|
// to "uninitialized" to allow for FDR-logging multiple runs.
|
|
|
|
auto ResetToUnitialized = at_scope_exit([] {
|
|
|
|
atomic_store(&LoggingStatus, XRayLogInitStatus::XRAY_LOG_UNINITIALIZED,
|
|
|
|
memory_order_release);
|
|
|
|
});
|
|
|
|
|
|
|
|
auto CleanupBuffers = at_scope_exit([] {
|
2018-10-30 12:35:48 +08:00
|
|
|
auto &TLD = getThreadLocalData();
|
|
|
|
if (TLD.Controller != nullptr)
|
|
|
|
TLD.Controller->flush();
|
2018-07-18 09:31:30 +08:00
|
|
|
});
|
|
|
|
|
2018-05-14 11:35:01 +08:00
|
|
|
if (fdrFlags()->no_file_flush) {
|
|
|
|
if (Verbosity())
|
|
|
|
Report("XRay FDR: Not flushing to file, 'no_file_flush=true'.\n");
|
|
|
|
|
2018-06-05 14:12:42 +08:00
|
|
|
atomic_store(&LogFlushStatus, XRayLogFlushStatus::XRAY_LOG_FLUSHED,
|
|
|
|
memory_order_release);
|
2018-05-14 11:35:01 +08:00
|
|
|
return XRayLogFlushStatus::XRAY_LOG_FLUSHED;
|
|
|
|
}
|
|
|
|
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
// We write out the file in the following format:
|
|
|
|
//
|
|
|
|
// 1) We write down the XRay file header with version 1, type FDR_LOG.
|
|
|
|
// 2) Then we use the 'apply' member of the BufferQueue that's live, to
|
|
|
|
// ensure that at this point in time we write down the buffers that have
|
|
|
|
// been released (and marked "used") -- we dump the full buffer for now
|
|
|
|
// (fixed-sized) and let the tools reading the buffers deal with the data
|
|
|
|
// afterwards.
|
|
|
|
//
|
2018-10-30 12:35:48 +08:00
|
|
|
LogWriter *LW = LogWriter::Open();
|
2018-10-16 09:24:46 +08:00
|
|
|
if (LW == nullptr) {
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
auto Result = XRayLogFlushStatus::XRAY_LOG_NOT_FLUSHING;
|
2018-06-05 14:12:42 +08:00
|
|
|
atomic_store(&LogFlushStatus, Result, memory_order_release);
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
2018-05-14 11:35:01 +08:00
|
|
|
XRayFileHeader Header = fdrCommonHeaderInfo();
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
Header.FdrData = FdrAdditionalHeaderData{BQ->ConfiguredBufferSize()};
|
2018-10-16 09:24:46 +08:00
|
|
|
LW->WriteAll(reinterpret_cast<char *>(&Header),
|
|
|
|
reinterpret_cast<char *>(&Header) + sizeof(Header));
|
2017-03-29 13:56:37 +08:00
|
|
|
|
2018-09-17 11:09:01 +08:00
|
|
|
// Release the current thread's buffer before we attempt to write out all the
|
|
|
|
// buffers. This ensures that in case we had only a single thread going, that
|
|
|
|
// we are able to capture the data nonetheless.
|
|
|
|
auto &TLD = getThreadLocalData();
|
2018-10-30 12:35:48 +08:00
|
|
|
if (TLD.Controller != nullptr)
|
|
|
|
TLD.Controller->flush();
|
2018-09-17 11:09:01 +08:00
|
|
|
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
BQ->apply([&](const BufferQueue::Buffer &B) {
|
|
|
|
// Starting at version 2 of the FDR logging implementation, we only write
|
|
|
|
// the records identified by the extents of the buffer. We use the Extents
|
2018-05-14 11:35:01 +08:00
|
|
|
// from the Buffer and write that out as the first record in the buffer. We
|
|
|
|
// still use a Metadata record, but fill in the extents instead for the
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
// data.
|
|
|
|
MetadataRecord ExtentsRecord;
|
2018-11-20 09:00:26 +08:00
|
|
|
auto BufferExtents = atomic_load(B.Extents, memory_order_acquire);
|
2018-06-05 18:27:20 +08:00
|
|
|
DCHECK(BufferExtents <= B.Size);
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
ExtentsRecord.Type = uint8_t(RecordType::Metadata);
|
|
|
|
ExtentsRecord.RecordKind =
|
|
|
|
uint8_t(MetadataRecord::RecordKinds::BufferExtents);
|
2018-06-05 16:20:54 +08:00
|
|
|
internal_memcpy(ExtentsRecord.Data, &BufferExtents, sizeof(BufferExtents));
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
if (BufferExtents > 0) {
|
2018-10-16 09:24:46 +08:00
|
|
|
LW->WriteAll(reinterpret_cast<char *>(&ExtentsRecord),
|
|
|
|
reinterpret_cast<char *>(&ExtentsRecord) +
|
2018-10-30 12:35:48 +08:00
|
|
|
sizeof(MetadataRecord));
|
2018-10-16 09:24:46 +08:00
|
|
|
LW->WriteAll(reinterpret_cast<char *>(B.Data),
|
|
|
|
reinterpret_cast<char *>(B.Data) + BufferExtents);
|
2017-03-29 13:56:37 +08:00
|
|
|
}
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
});
|
2017-10-04 13:12:00 +08:00
|
|
|
|
2018-06-05 14:12:42 +08:00
|
|
|
atomic_store(&LogFlushStatus, XRayLogFlushStatus::XRAY_LOG_FLUSHED,
|
|
|
|
memory_order_release);
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
return XRayLogFlushStatus::XRAY_LOG_FLUSHED;
|
|
|
|
}
|
|
|
|
|
2017-02-08 07:35:34 +08:00
|
|
|
XRayLogInitStatus fdrLoggingFinalize() XRAY_NEVER_INSTRUMENT {
|
2017-03-27 15:13:35 +08:00
|
|
|
s32 CurrentStatus = XRayLogInitStatus::XRAY_LOG_INITIALIZED;
|
2018-06-05 14:12:42 +08:00
|
|
|
if (!atomic_compare_exchange_strong(&LoggingStatus, &CurrentStatus,
|
|
|
|
XRayLogInitStatus::XRAY_LOG_FINALIZING,
|
|
|
|
memory_order_release)) {
|
|
|
|
if (Verbosity())
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
Report("Cannot finalize log, implementation not initialized.\n");
|
2017-03-27 15:13:35 +08:00
|
|
|
return static_cast<XRayLogInitStatus>(CurrentStatus);
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
}
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
|
|
|
|
// Do special things to make the log finalize itself, and not allow any more
|
|
|
|
// operations to be performed until re-initialized.
|
2018-09-17 11:09:01 +08:00
|
|
|
if (BQ == nullptr) {
|
|
|
|
if (Verbosity())
|
|
|
|
Report("Attempting to finalize an uninitialized global buffer!\n");
|
|
|
|
} else {
|
|
|
|
BQ->finalize();
|
|
|
|
}
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
|
2018-06-05 14:12:42 +08:00
|
|
|
atomic_store(&LoggingStatus, XRayLogInitStatus::XRAY_LOG_FINALIZED,
|
|
|
|
memory_order_release);
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
return XRayLogInitStatus::XRAY_LOG_FINALIZED;
|
|
|
|
}
|
|
|
|
|
2017-10-28 07:59:41 +08:00
|
|
|
struct TSCAndCPU {
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
uint64_t TSC = 0;
|
|
|
|
unsigned char CPU = 0;
|
2017-10-28 07:59:41 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
static TSCAndCPU getTimestamp() XRAY_NEVER_INSTRUMENT {
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
// We want to get the TSC as early as possible, so that we can check whether
|
2018-05-14 11:35:01 +08:00
|
|
|
// we've seen this CPU before. We also do it before we load anything else,
|
|
|
|
// to allow for forward progress with the scheduling.
|
2017-10-28 07:59:41 +08:00
|
|
|
TSCAndCPU Result;
|
2017-04-11 15:45:16 +08:00
|
|
|
|
2017-04-18 11:25:11 +08:00
|
|
|
// Test once for required CPU features
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
static pthread_once_t OnceProbe = PTHREAD_ONCE_INIT;
|
|
|
|
static bool TSCSupported = true;
|
2018-11-07 12:37:42 +08:00
|
|
|
pthread_once(
|
|
|
|
&OnceProbe, +[] { TSCSupported = probeRequiredCPUFeatures(); });
|
2017-04-18 11:25:11 +08:00
|
|
|
|
2017-05-12 09:07:41 +08:00
|
|
|
if (TSCSupported) {
|
2017-10-28 07:59:41 +08:00
|
|
|
Result.TSC = __xray::readTSC(Result.CPU);
|
2017-04-11 15:45:16 +08:00
|
|
|
} else {
|
|
|
|
// FIXME: This code needs refactoring as it appears in multiple locations
|
|
|
|
timespec TS;
|
|
|
|
int result = clock_gettime(CLOCK_REALTIME, &TS);
|
|
|
|
if (result != 0) {
|
|
|
|
Report("clock_gettime(2) return %d, errno=%d", result, int(errno));
|
|
|
|
TS = {0, 0};
|
|
|
|
}
|
2017-10-28 07:59:41 +08:00
|
|
|
Result.CPU = 0;
|
|
|
|
Result.TSC = TS.tv_sec * __xray::NanosecondsPerSecond + TS.tv_nsec;
|
2017-04-11 15:45:16 +08:00
|
|
|
}
|
2017-10-28 07:59:41 +08:00
|
|
|
return Result;
|
2017-05-12 09:07:41 +08:00
|
|
|
}
|
|
|
|
|
2018-10-30 12:35:48 +08:00
|
|
|
thread_local atomic_uint8_t Running{0};
|
|
|
|
|
|
|
|
static bool setupTLD(ThreadLocalData &TLD) XRAY_NEVER_INSTRUMENT {
|
|
|
|
// Check if we're finalizing, before proceeding.
|
|
|
|
{
|
|
|
|
auto Status = atomic_load(&LoggingStatus, memory_order_acquire);
|
|
|
|
if (Status == XRayLogInitStatus::XRAY_LOG_FINALIZING ||
|
|
|
|
Status == XRayLogInitStatus::XRAY_LOG_FINALIZED) {
|
|
|
|
if (TLD.Controller != nullptr) {
|
|
|
|
TLD.Controller->flush();
|
|
|
|
TLD.Controller = nullptr;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (UNLIKELY(TLD.Controller == nullptr)) {
|
|
|
|
// Set up the TLD buffer queue.
|
|
|
|
if (UNLIKELY(BQ == nullptr))
|
|
|
|
return false;
|
|
|
|
TLD.BQ = BQ;
|
|
|
|
|
|
|
|
// Check that we have a valid buffer.
|
|
|
|
if (TLD.Buffer.Generation != BQ->generation() &&
|
|
|
|
TLD.BQ->releaseBuffer(TLD.Buffer) != BufferQueue::ErrorCode::Ok)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// Set up a buffer, before setting up the log writer. Bail out on failure.
|
|
|
|
if (TLD.BQ->getBuffer(TLD.Buffer) != BufferQueue::ErrorCode::Ok)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// Set up the Log Writer for this thread.
|
|
|
|
if (UNLIKELY(TLD.Writer == nullptr)) {
|
|
|
|
auto *LWStorage = reinterpret_cast<FDRLogWriter *>(&TLD.LWStorage);
|
|
|
|
new (LWStorage) FDRLogWriter(TLD.Buffer);
|
|
|
|
TLD.Writer = LWStorage;
|
|
|
|
} else {
|
|
|
|
TLD.Writer->resetRecord();
|
|
|
|
}
|
|
|
|
|
|
|
|
auto *CStorage = reinterpret_cast<FDRController<> *>(&TLD.CStorage);
|
|
|
|
new (CStorage)
|
|
|
|
FDRController<>(TLD.BQ, TLD.Buffer, *TLD.Writer, clock_gettime,
|
|
|
|
atomic_load_relaxed(&ThresholdTicks));
|
|
|
|
TLD.Controller = CStorage;
|
|
|
|
}
|
|
|
|
|
|
|
|
DCHECK_NE(TLD.Controller, nullptr);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2017-05-12 09:07:41 +08:00
|
|
|
void fdrLoggingHandleArg0(int32_t FuncId,
|
|
|
|
XRayEntryType Entry) XRAY_NEVER_INSTRUMENT {
|
2017-10-28 07:59:41 +08:00
|
|
|
auto TC = getTimestamp();
|
2018-10-30 12:35:48 +08:00
|
|
|
auto &TSC = TC.TSC;
|
|
|
|
auto &CPU = TC.CPU;
|
|
|
|
RecursionGuard Guard{Running};
|
|
|
|
if (!Guard)
|
|
|
|
return;
|
|
|
|
|
|
|
|
auto &TLD = getThreadLocalData();
|
|
|
|
if (!setupTLD(TLD))
|
|
|
|
return;
|
|
|
|
|
|
|
|
switch (Entry) {
|
|
|
|
case XRayEntryType::ENTRY:
|
|
|
|
case XRayEntryType::LOG_ARGS_ENTRY:
|
|
|
|
TLD.Controller->functionEnter(FuncId, TSC, CPU);
|
|
|
|
return;
|
|
|
|
case XRayEntryType::EXIT:
|
|
|
|
TLD.Controller->functionExit(FuncId, TSC, CPU);
|
|
|
|
return;
|
|
|
|
case XRayEntryType::TAIL:
|
|
|
|
TLD.Controller->functionTailExit(FuncId, TSC, CPU);
|
|
|
|
return;
|
|
|
|
case XRayEntryType::CUSTOM_EVENT:
|
|
|
|
case XRayEntryType::TYPED_EVENT:
|
|
|
|
break;
|
|
|
|
}
|
2017-09-28 13:29:59 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void fdrLoggingHandleArg1(int32_t FuncId, XRayEntryType Entry,
|
|
|
|
uint64_t Arg) XRAY_NEVER_INSTRUMENT {
|
2017-10-28 07:59:41 +08:00
|
|
|
auto TC = getTimestamp();
|
2018-10-30 12:35:48 +08:00
|
|
|
auto &TSC = TC.TSC;
|
|
|
|
auto &CPU = TC.CPU;
|
|
|
|
RecursionGuard Guard{Running};
|
|
|
|
if (!Guard)
|
|
|
|
return;
|
|
|
|
|
|
|
|
auto &TLD = getThreadLocalData();
|
|
|
|
if (!setupTLD(TLD))
|
|
|
|
return;
|
|
|
|
|
|
|
|
switch (Entry) {
|
|
|
|
case XRayEntryType::ENTRY:
|
|
|
|
case XRayEntryType::LOG_ARGS_ENTRY:
|
|
|
|
TLD.Controller->functionEnterArg(FuncId, TSC, CPU, Arg);
|
|
|
|
return;
|
|
|
|
case XRayEntryType::EXIT:
|
|
|
|
TLD.Controller->functionExit(FuncId, TSC, CPU);
|
|
|
|
return;
|
|
|
|
case XRayEntryType::TAIL:
|
|
|
|
TLD.Controller->functionTailExit(FuncId, TSC, CPU);
|
|
|
|
return;
|
|
|
|
case XRayEntryType::CUSTOM_EVENT:
|
|
|
|
case XRayEntryType::TYPED_EVENT:
|
|
|
|
break;
|
|
|
|
}
|
2017-05-12 09:07:41 +08:00
|
|
|
}
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
|
2017-05-12 09:07:41 +08:00
|
|
|
void fdrLoggingHandleCustomEvent(void *Event,
|
|
|
|
std::size_t EventSize) XRAY_NEVER_INSTRUMENT {
|
2017-10-28 07:59:41 +08:00
|
|
|
auto TC = getTimestamp();
|
|
|
|
auto &TSC = TC.TSC;
|
|
|
|
auto &CPU = TC.CPU;
|
2017-05-12 09:07:41 +08:00
|
|
|
RecursionGuard Guard{Running};
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
if (!Guard)
|
2017-05-12 09:07:41 +08:00
|
|
|
return;
|
2018-10-30 12:35:48 +08:00
|
|
|
|
|
|
|
// Complain when we ever get at least one custom event that's larger than what
|
|
|
|
// we can possibly support.
|
|
|
|
if (EventSize >
|
|
|
|
static_cast<std::size_t>(std::numeric_limits<int32_t>::max())) {
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
static pthread_once_t Once = PTHREAD_ONCE_INIT;
|
2018-11-07 12:37:42 +08:00
|
|
|
pthread_once(
|
|
|
|
&Once, +[] {
|
|
|
|
Report("Custom event size too large; truncating to %d.\n",
|
|
|
|
std::numeric_limits<int32_t>::max());
|
|
|
|
});
|
2017-05-12 09:07:41 +08:00
|
|
|
}
|
|
|
|
|
2018-10-30 12:35:48 +08:00
|
|
|
auto &TLD = getThreadLocalData();
|
|
|
|
if (!setupTLD(TLD))
|
2017-05-12 09:07:41 +08:00
|
|
|
return;
|
|
|
|
|
2018-10-30 12:35:48 +08:00
|
|
|
int32_t ReducedEventSize = static_cast<int32_t>(EventSize);
|
|
|
|
TLD.Controller->customEvent(TSC, CPU, Event, ReducedEventSize);
|
2017-05-12 09:07:41 +08:00
|
|
|
}
|
|
|
|
|
2018-04-18 05:28:53 +08:00
|
|
|
void fdrLoggingHandleTypedEvent(
|
|
|
|
uint16_t EventType, const void *Event,
|
|
|
|
std::size_t EventSize) noexcept XRAY_NEVER_INSTRUMENT {
|
|
|
|
auto TC = getTimestamp();
|
|
|
|
auto &TSC = TC.TSC;
|
|
|
|
auto &CPU = TC.CPU;
|
|
|
|
RecursionGuard Guard{Running};
|
|
|
|
if (!Guard)
|
|
|
|
return;
|
2018-10-30 12:35:48 +08:00
|
|
|
|
|
|
|
// Complain when we ever get at least one typed event that's larger than what
|
|
|
|
// we can possibly support.
|
|
|
|
if (EventSize >
|
|
|
|
static_cast<std::size_t>(std::numeric_limits<int32_t>::max())) {
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
static pthread_once_t Once = PTHREAD_ONCE_INIT;
|
2018-11-07 12:37:42 +08:00
|
|
|
pthread_once(
|
|
|
|
&Once, +[] {
|
|
|
|
Report("Typed event size too large; truncating to %d.\n",
|
|
|
|
std::numeric_limits<int32_t>::max());
|
|
|
|
});
|
2018-04-18 05:28:53 +08:00
|
|
|
}
|
2018-10-30 12:35:48 +08:00
|
|
|
|
2018-04-18 05:28:53 +08:00
|
|
|
auto &TLD = getThreadLocalData();
|
2018-10-30 12:35:48 +08:00
|
|
|
if (!setupTLD(TLD))
|
2018-04-18 05:28:53 +08:00
|
|
|
return;
|
|
|
|
|
2018-10-30 12:35:48 +08:00
|
|
|
int32_t ReducedEventSize = static_cast<int32_t>(EventSize);
|
|
|
|
TLD.Controller->typedEvent(TSC, CPU, EventType, Event, ReducedEventSize);
|
2018-04-18 05:28:53 +08:00
|
|
|
}
|
|
|
|
|
2018-10-22 12:53:58 +08:00
|
|
|
XRayLogInitStatus fdrLoggingInit(size_t, size_t, void *Options,
|
2017-05-12 09:07:41 +08:00
|
|
|
size_t OptionsSize) XRAY_NEVER_INSTRUMENT {
|
2018-05-04 14:13:35 +08:00
|
|
|
if (Options == nullptr)
|
|
|
|
return XRayLogInitStatus::XRAY_LOG_UNINITIALIZED;
|
|
|
|
|
2017-05-12 09:07:41 +08:00
|
|
|
s32 CurrentStatus = XRayLogInitStatus::XRAY_LOG_UNINITIALIZED;
|
2018-06-05 14:12:42 +08:00
|
|
|
if (!atomic_compare_exchange_strong(&LoggingStatus, &CurrentStatus,
|
|
|
|
XRayLogInitStatus::XRAY_LOG_INITIALIZING,
|
|
|
|
memory_order_release)) {
|
|
|
|
if (Verbosity())
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
Report("Cannot initialize already initialized implementation.\n");
|
2017-05-12 09:07:41 +08:00
|
|
|
return static_cast<XRayLogInitStatus>(CurrentStatus);
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
}
|
2017-05-12 09:07:41 +08:00
|
|
|
|
2018-09-15 10:55:42 +08:00
|
|
|
if (Verbosity())
|
|
|
|
Report("Initializing FDR mode with options: %s\n",
|
|
|
|
static_cast<const char *>(Options));
|
|
|
|
|
|
|
|
// TODO: Factor out the flags specific to the FDR mode implementation. For
|
|
|
|
// now, use the global/single definition of the flags, since the FDR mode
|
|
|
|
// flags are already defined there.
|
|
|
|
FlagParser FDRParser;
|
|
|
|
FDRFlags FDRFlags;
|
|
|
|
registerXRayFDRFlags(&FDRParser, &FDRFlags);
|
|
|
|
FDRFlags.setDefaults();
|
|
|
|
|
|
|
|
// Override first from the general XRAY_DEFAULT_OPTIONS compiler-provided
|
|
|
|
// options until we migrate everyone to use the XRAY_FDR_OPTIONS
|
|
|
|
// compiler-provided options.
|
|
|
|
FDRParser.ParseString(useCompilerDefinedFlags());
|
|
|
|
FDRParser.ParseString(useCompilerDefinedFDRFlags());
|
|
|
|
auto *EnvOpts = GetEnv("XRAY_FDR_OPTIONS");
|
|
|
|
if (EnvOpts == nullptr)
|
|
|
|
EnvOpts = "";
|
|
|
|
FDRParser.ParseString(EnvOpts);
|
|
|
|
|
|
|
|
// FIXME: Remove this when we fully remove the deprecated flags.
|
|
|
|
if (internal_strlen(EnvOpts) == 0) {
|
|
|
|
FDRFlags.func_duration_threshold_us =
|
|
|
|
flags()->xray_fdr_log_func_duration_threshold_us;
|
|
|
|
FDRFlags.grace_period_ms = flags()->xray_fdr_log_grace_period_ms;
|
2017-05-12 09:07:41 +08:00
|
|
|
}
|
|
|
|
|
2018-09-15 10:55:42 +08:00
|
|
|
// The provided options should always override the compiler-provided and
|
|
|
|
// environment-variable defined options.
|
|
|
|
FDRParser.ParseString(static_cast<const char *>(Options));
|
|
|
|
*fdrFlags() = FDRFlags;
|
2018-10-22 12:53:58 +08:00
|
|
|
auto BufferSize = FDRFlags.buffer_size;
|
|
|
|
auto BufferMax = FDRFlags.buffer_max;
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
if (BQ == nullptr) {
|
2018-10-30 12:35:48 +08:00
|
|
|
bool Success = false;
|
2018-09-17 11:09:01 +08:00
|
|
|
BQ = reinterpret_cast<BufferQueue *>(&BufferQueueStorage);
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
new (BQ) BufferQueue(BufferSize, BufferMax, Success);
|
2018-10-30 12:35:48 +08:00
|
|
|
if (!Success) {
|
|
|
|
Report("BufferQueue init failed.\n");
|
|
|
|
return XRayLogInitStatus::XRAY_LOG_UNINITIALIZED;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
if (BQ->init(BufferSize, BufferMax) != BufferQueue::ErrorCode::Ok) {
|
|
|
|
if (Verbosity())
|
|
|
|
Report("Failed to re-initialize global buffer queue. Init failed.\n");
|
|
|
|
return XRayLogInitStatus::XRAY_LOG_UNINITIALIZED;
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
}
|
2017-05-12 09:07:41 +08:00
|
|
|
}
|
|
|
|
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
static pthread_once_t OnceInit = PTHREAD_ONCE_INIT;
|
2018-11-07 12:37:42 +08:00
|
|
|
pthread_once(
|
|
|
|
&OnceInit, +[] {
|
|
|
|
atomic_store(&TicksPerSec,
|
|
|
|
probeRequiredCPUFeatures() ? getTSCFrequency()
|
|
|
|
: __xray::NanosecondsPerSecond,
|
|
|
|
memory_order_release);
|
|
|
|
pthread_key_create(
|
|
|
|
&Key, +[](void *TLDPtr) {
|
|
|
|
if (TLDPtr == nullptr)
|
|
|
|
return;
|
|
|
|
auto &TLD = *reinterpret_cast<ThreadLocalData *>(TLDPtr);
|
|
|
|
if (TLD.BQ == nullptr)
|
|
|
|
return;
|
|
|
|
if (TLD.Buffer.Data == nullptr)
|
|
|
|
return;
|
|
|
|
auto EC = TLD.BQ->releaseBuffer(TLD.Buffer);
|
|
|
|
if (EC != BufferQueue::ErrorCode::Ok)
|
|
|
|
Report("At thread exit, failed to release buffer at %p; "
|
|
|
|
"error=%s\n",
|
|
|
|
TLD.Buffer.Data, BufferQueue::getErrorString(EC));
|
|
|
|
});
|
|
|
|
});
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
|
[XRay][compiler-rt] Remove reliance on C++ ABI features
Summary:
This fixes http://llvm.org/PR32274.
This change adds a test to ensure that we're able to link XRay modes and
the runtime to binaries that don't need to depend on the C++ standard
library or a C++ ABI library. In particular, we ensure that this will work
with C programs compiled+linked with XRay.
To make the test pass, we need to change a few things in the XRay
runtime implementations to remove the reliance on C++ ABI features. In
particular, we change the thread-safe function-local-static
initialisation to use pthread_* instead of the C++ features that ensure
non-trivial thread-local/function-local-static initialisation.
Depends on D47696.
Reviewers: dblaikie, jfb, kpw, eizan
Reviewed By: kpw
Subscribers: echristo, eizan, kpw, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46998
llvm-svn: 334262
2018-06-08 12:00:07 +08:00
|
|
|
atomic_store(&ThresholdTicks,
|
|
|
|
atomic_load_relaxed(&TicksPerSec) *
|
|
|
|
fdrFlags()->func_duration_threshold_us / 1000000,
|
|
|
|
memory_order_release);
|
2017-09-28 13:29:59 +08:00
|
|
|
// Arg1 handler should go in first to avoid concurrent code accidentally
|
|
|
|
// falling back to arg0 when it should have ran arg1.
|
|
|
|
__xray_set_handler_arg1(fdrLoggingHandleArg1);
|
2017-05-12 09:07:41 +08:00
|
|
|
// Install the actual handleArg0 handler after initialising the buffers.
|
|
|
|
__xray_set_handler(fdrLoggingHandleArg0);
|
|
|
|
__xray_set_customevent_handler(fdrLoggingHandleCustomEvent);
|
2018-04-18 05:28:53 +08:00
|
|
|
__xray_set_typedevent_handler(fdrLoggingHandleTypedEvent);
|
2017-05-12 09:07:41 +08:00
|
|
|
|
2018-05-14 11:35:01 +08:00
|
|
|
// Install the buffer iterator implementation.
|
|
|
|
__xray_log_set_buffer_iterator(fdrIterator);
|
|
|
|
|
2018-06-05 14:12:42 +08:00
|
|
|
atomic_store(&LoggingStatus, XRayLogInitStatus::XRAY_LOG_INITIALIZED,
|
|
|
|
memory_order_release);
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
|
2018-06-05 14:12:42 +08:00
|
|
|
if (Verbosity())
|
[XRay] Use optimistic logging model for FDR mode
Summary:
Before this change, the FDR mode implementation relied on at thread-exit
handling to return buffers back to the (global) buffer queue. This
introduces issues with the initialisation of the thread_local objects
which, even through the use of pthread_setspecific(...) may eventually
call into an allocation function. Similar to previous changes in this
line, we're finding that there is a huge potential for deadlocks when
initialising these thread-locals when the memory allocation
implementation is also xray-instrumented.
In this change, we limit the call to pthread_setspecific(...) to provide
a non-null value to associate to the key created with
pthread_key_create(...). While this doesn't completely eliminate the
potential for the deadlock(s), it does allow us to still clean up at
thread exit when we need to. The change is that we don't need to do more
work when starting and ending a thread's lifetime. We also have a test
to make sure that we actually can safely recycle the buffers in case we
end up re-using the buffer(s) available from the queue on multiple
thread entry/exits.
This change cuts across both LLVM and compiler-rt to allow us to update
both the XRay runtime implementation as well as the library support for
loading these new versions of the FDR mode logging. Version 2 of the FDR
logging implementation makes the following changes:
* Introduction of a new 'BufferExtents' metadata record that's outside
of the buffer's contents but are written before the actual buffer.
This data is associated to the Buffer handed out by the BufferQueue
rather than a record that occupies bytes in the actual buffer.
* Removal of the "end of buffer" records. This is in-line with the
changes we described above, to allow for optimistic logging without
explicit record writing at thread exit.
The optimistic logging model operates under the following assumptions:
* Threads writing to the buffers will potentially race with the thread
attempting to flush the log. To avoid this situation from occuring,
we make sure that when we've finalized the logging implementation,
that threads will see this finalization state on the next write, and
either choose to not write records the thread would have written or
write the record(s) in two phases -- first write the record(s), then
update the extents metadata.
* We change the buffer queue implementation so that once it's handed
out a buffer to a thread, that we assume that buffer is marked
"used" to be able to capture partial writes. None of this will be
safe to handle if threads are racing to write the extents records
and the reader thread is attempting to flush the log. The optimism
comes from the finalization routine being required to complete
before we attempt to flush the log.
This is a fairly significant semantics change for the FDR
implementation. This is why we've decided to update the version number
for FDR mode logs. The tools, however, still need to be able to support
older versions of the log until we finally deprecate those earlier
versions.
Reviewers: dblaikie, pelikan, kpw
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D39526
llvm-svn: 318733
2017-11-21 15:16:57 +08:00
|
|
|
Report("XRay FDR init successful.\n");
|
2017-05-12 09:07:41 +08:00
|
|
|
return XRayLogInitStatus::XRAY_LOG_INITIALIZED;
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
}
|
|
|
|
|
2017-12-05 20:08:56 +08:00
|
|
|
bool fdrLogDynamicInitializer() XRAY_NEVER_INSTRUMENT {
|
|
|
|
XRayLogImpl Impl{
|
|
|
|
fdrLoggingInit,
|
|
|
|
fdrLoggingFinalize,
|
|
|
|
fdrLoggingHandleArg0,
|
|
|
|
fdrLoggingFlush,
|
|
|
|
};
|
|
|
|
auto RegistrationResult = __xray_log_register_mode("xray-fdr", Impl);
|
|
|
|
if (RegistrationResult != XRayLogRegisterStatus::XRAY_REGISTRATION_OK &&
|
2018-09-17 10:49:17 +08:00
|
|
|
Verbosity()) {
|
2017-12-05 20:08:56 +08:00
|
|
|
Report("Cannot register XRay FDR mode to 'xray-fdr'; error = %d\n",
|
|
|
|
RegistrationResult);
|
2018-09-17 10:49:17 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (flags()->xray_fdr_log ||
|
|
|
|
!internal_strcmp(flags()->xray_mode, "xray-fdr")) {
|
|
|
|
auto SelectResult = __xray_log_select_mode("xray-fdr");
|
|
|
|
if (SelectResult != XRayLogRegisterStatus::XRAY_REGISTRATION_OK &&
|
|
|
|
Verbosity()) {
|
|
|
|
Report("Cannot select XRay FDR mode as 'xray-fdr'; error = %d\n",
|
|
|
|
SelectResult);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
[XRay][compiler-rt] XRay Flight Data Recorder Mode
Summary:
In this change we introduce the notion of a "flight data recorder" mode
for XRay logging, where XRay logs in-memory first, and write out data
on-demand as required (as opposed to the naive implementation that keeps
logging while tracing is "on"). This depends on D26232 where we
implement the core data structure for holding the buffers that threads
will be using to write out records of operation.
This implementation only currently works on x86_64 and depends heavily
on the TSC math to write out smaller records to the inmemory buffers.
Also, this implementation defines two different kinds of records with
different sizes (compared to the current naive implementation): a
MetadataRecord (16 bytes) and a FunctionRecord (8 bytes). MetadataRecord
entries are meant to write out information like the thread ID for which
the metadata record is defined for, whether the execution of a thread
moved to a different CPU, etc. while a FunctionRecord represents the
different kinds of function call entry/exit records we might encounter
in the course of a thread's execution along with a delta from the last
time the logging handler was called.
While this implementation is not exactly what is described in the
original XRay whitepaper, this one gives us an initial implementation
that we can iterate and build upon.
Reviewers: echristo, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27038
llvm-svn: 293015
2017-01-25 11:50:46 +08:00
|
|
|
return true;
|
2017-12-05 20:08:56 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
} // namespace __xray
|
|
|
|
|
|
|
|
static auto UNUSED Unused = __xray::fdrLogDynamicInitializer();
|