maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/compiler-rt/lib/xray/xray_profiling_flags.inc

32 lines
1.4 KiB
PHP
Raw Normal View History

[XRay][profiler] Part 4: Profiler Mode Wiring Summary: This is part of the larger XRay Profiling Mode effort. This patch implements the wiring required to enable us to actually select the `xray-profiling` mode, and install the handlers to start measuring the time and frequency of the function calls in call stacks. The current way to get the profile information is by working with the XRay API to `__xray_process_buffers(...)`. In subsequent changes we'll implement profile saving to files, similar to how the FDR and basic modes operate, as well as means for converting this format into those that can be loaded/visualised as flame graphs. We will also be extending the accounting tool in LLVM to support stack-based function call accounting. We also continue with the implementation to support building small histograms of latencies for the `FunctionCallTrie::Node` type, to allow us to actually approximate the distribution of latencies per function. Depends on D45758 and D46998. Reviewers: eizan, kpw, pelikan Reviewed By: kpw Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D44620 llvm-svn: 334469
2018-06-12 11:29:39 +08:00
//===-- xray_profiling_flags.inc --------------------------------*- C++ -*-===//
[XRay][profiler] Part 2: XRay Function Call Trie Summary: This is part of the larger XRay Profiling Mode effort. This patch implements a central data structure for capturing statistics about XRay instrumented function call stacks. The `FunctionCallTrie` type does the following things: * It keeps track of a shadow function call stack of XRay instrumented functions as they are entered (function enter event) and as they are exited (function exit event). * When a function is entered, the shadow stack contains information about the entry TSC, and updates the trie (or prefix tree) representing the current function call stack. If we haven't encountered this function call before, this creates a unique node for the function in this position on the stack. We update the list of callees of the parent function as well to reflect this newly found path. * When a function is exited, we compute statistics (TSC deltas, function call count frequency) for the associated function(s) up the stack as we unwind to find the matching entry event. This builds upon the XRay `Allocator` and `Array` types in Part 1 of this series of patches. Depends on D45756. Reviewers: echristo, pelikan, kpw Reviewed By: kpw Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D45757 llvm-svn: 332313
2018-05-15 08:42:36 +08:00
//
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
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][profiler] Part 2: XRay Function Call Trie Summary: This is part of the larger XRay Profiling Mode effort. This patch implements a central data structure for capturing statistics about XRay instrumented function call stacks. The `FunctionCallTrie` type does the following things: * It keeps track of a shadow function call stack of XRay instrumented functions as they are entered (function enter event) and as they are exited (function exit event). * When a function is entered, the shadow stack contains information about the entry TSC, and updates the trie (or prefix tree) representing the current function call stack. If we haven't encountered this function call before, this creates a unique node for the function in this position on the stack. We update the list of callees of the parent function as well to reflect this newly found path. * When a function is exited, we compute statistics (TSC deltas, function call count frequency) for the associated function(s) up the stack as we unwind to find the matching entry event. This builds upon the XRay `Allocator` and `Array` types in Part 1 of this series of patches. Depends on D45756. Reviewers: echristo, pelikan, kpw Reviewed By: kpw Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D45757 llvm-svn: 332313
2018-05-15 08:42:36 +08:00
//
//===----------------------------------------------------------------------===//
//
// XRay profiling runtime flags.
//
//===----------------------------------------------------------------------===//
#ifndef XRAY_FLAG
#error "Define XRAY_FLAG prior to including this file!"
#endif
[XRay] Use preallocated memory for XRay profiling Summary: This change builds upon D54989, which removes memory allocation from the critical path of the profiling implementation. This also changes the API for the profile collection service, to take ownership of the memory and associated data structures per-thread. The consolidation of the memory allocation allows us to do two things: - Limits the amount of memory used by the profiling implementation, associating preallocated buffers instead of allocating memory on-demand. - Consolidate the memory initialisation and cleanup by relying on the buffer queue's reference counting implementation. We find a number of places which also display some problematic behaviour, including: - Off-by-factor bug in the allocator implementation. - Unrolling semantics in cases of "memory exhausted" situations, when managing the state of the function call trie. We also add a few test cases which verify our understanding of the behaviour of the system, with important edge-cases (especially for memory-exhausted cases) in the segmented array and profile collector unit tests. Depends on D54989. Reviewers: mboerger Subscribers: dschuff, mgorny, dmgreen, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D55249 llvm-svn: 348568
2018-12-07 14:23:06 +08:00
XRAY_FLAG(uptr, per_thread_allocator_max, 16384,
[XRay][profiler] Part 2: XRay Function Call Trie Summary: This is part of the larger XRay Profiling Mode effort. This patch implements a central data structure for capturing statistics about XRay instrumented function call stacks. The `FunctionCallTrie` type does the following things: * It keeps track of a shadow function call stack of XRay instrumented functions as they are entered (function enter event) and as they are exited (function exit event). * When a function is entered, the shadow stack contains information about the entry TSC, and updates the trie (or prefix tree) representing the current function call stack. If we haven't encountered this function call before, this creates a unique node for the function in this position on the stack. We update the list of callees of the parent function as well to reflect this newly found path. * When a function is exited, we compute statistics (TSC deltas, function call count frequency) for the associated function(s) up the stack as we unwind to find the matching entry event. This builds upon the XRay `Allocator` and `Array` types in Part 1 of this series of patches. Depends on D45756. Reviewers: echristo, pelikan, kpw Reviewed By: kpw Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D45757 llvm-svn: 332313
2018-05-15 08:42:36 +08:00
"Maximum size of any single per-thread allocator.")
XRAY_FLAG(uptr, global_allocator_max, 2 << 24,
"Maximum size of the global allocator for profile storage.")
[XRay][compiler-rt] Simplify Allocator Implementation Summary: This change simplifies the XRay Allocator implementation to self-manage an mmap'ed memory segment instead of using the internal allocator implementation in sanitizer_common. We've found through benchmarks and profiling these benchmarks in D48879 that using the internal allocator in sanitizer_common introduces a bottleneck on allocating memory through a central spinlock. This change allows thread-local allocators to eliminate contention on the centralized allocator. To get the most benefit from this approach, we also use a managed allocator for the chunk elements used by the segmented array implementation. This gives us the chance to amortize the cost of allocating memory when creating these internal segmented array data structures. We also took the opportunity to remove the preallocation argument from the allocator API, simplifying the usage of the allocator throughout the profiling implementation. In this change we also tweak some of the flag values to reduce the amount of maximum memory we use/need for each thread, when requesting memory through mmap. Depends on D48956. Reviewers: kpw, eizan Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49217 llvm-svn: 337342
2018-07-18 09:53:39 +08:00
XRAY_FLAG(uptr, stack_allocator_max, 2 << 20,
[XRay][profiler] Part 2: XRay Function Call Trie Summary: This is part of the larger XRay Profiling Mode effort. This patch implements a central data structure for capturing statistics about XRay instrumented function call stacks. The `FunctionCallTrie` type does the following things: * It keeps track of a shadow function call stack of XRay instrumented functions as they are entered (function enter event) and as they are exited (function exit event). * When a function is entered, the shadow stack contains information about the entry TSC, and updates the trie (or prefix tree) representing the current function call stack. If we haven't encountered this function call before, this creates a unique node for the function in this position on the stack. We update the list of callees of the parent function as well to reflect this newly found path. * When a function is exited, we compute statistics (TSC deltas, function call count frequency) for the associated function(s) up the stack as we unwind to find the matching entry event. This builds upon the XRay `Allocator` and `Array` types in Part 1 of this series of patches. Depends on D45756. Reviewers: echristo, pelikan, kpw Reviewed By: kpw Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D45757 llvm-svn: 332313
2018-05-15 08:42:36 +08:00
"Maximum size of the traversal stack allocator.")
[XRay][compiler-rt] Profiling Mode: Flush logs on exit Summary: This change adds support for writing out profiles at program exit. Depends on D48653. Reviewers: kpw, eizan Reviewed By: kpw Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D48956 llvm-svn: 336969
2018-07-13 12:04:18 +08:00
XRAY_FLAG(int, grace_period_ms, 1,
[XRay][profiler] Part 2: XRay Function Call Trie Summary: This is part of the larger XRay Profiling Mode effort. This patch implements a central data structure for capturing statistics about XRay instrumented function call stacks. The `FunctionCallTrie` type does the following things: * It keeps track of a shadow function call stack of XRay instrumented functions as they are entered (function enter event) and as they are exited (function exit event). * When a function is entered, the shadow stack contains information about the entry TSC, and updates the trie (or prefix tree) representing the current function call stack. If we haven't encountered this function call before, this creates a unique node for the function in this position on the stack. We update the list of callees of the parent function as well to reflect this newly found path. * When a function is exited, we compute statistics (TSC deltas, function call count frequency) for the associated function(s) up the stack as we unwind to find the matching entry event. This builds upon the XRay `Allocator` and `Array` types in Part 1 of this series of patches. Depends on D45756. Reviewers: echristo, pelikan, kpw Reviewed By: kpw Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D45757 llvm-svn: 332313
2018-05-15 08:42:36 +08:00
"Profile collection will wait this much time in milliseconds before "
"resetting the global state. This gives a chance to threads to "
"notice that the profiler has been finalized and clean up.")
[XRay][profiler] Part 5: Profiler File Writing Summary: This is part of the larger XRay Profiling Mode effort. This patch implements the profile writing mechanism, to allow profiles collected through the profiler mode to be persisted to files. Follow-on patches would allow us to load these profiles and start converting/analysing them through the `llvm-xray` tool. Depends on D44620. Reviewers: echristo, kpw, pelikan Reviewed By: kpw Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45998 llvm-svn: 334472
2018-06-12 12:06:25 +08:00
XRAY_FLAG(bool, no_flush, false,
"Set to true if we want the profiling implementation to not write "
"out files.")
[XRay] Use preallocated memory for XRay profiling Summary: This change builds upon D54989, which removes memory allocation from the critical path of the profiling implementation. This also changes the API for the profile collection service, to take ownership of the memory and associated data structures per-thread. The consolidation of the memory allocation allows us to do two things: - Limits the amount of memory used by the profiling implementation, associating preallocated buffers instead of allocating memory on-demand. - Consolidate the memory initialisation and cleanup by relying on the buffer queue's reference counting implementation. We find a number of places which also display some problematic behaviour, including: - Off-by-factor bug in the allocator implementation. - Unrolling semantics in cases of "memory exhausted" situations, when managing the state of the function call trie. We also add a few test cases which verify our understanding of the behaviour of the system, with important edge-cases (especially for memory-exhausted cases) in the segmented array and profile collector unit tests. Depends on D54989. Reviewers: mboerger Subscribers: dschuff, mgorny, dmgreen, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D55249 llvm-svn: 348568
2018-12-07 14:23:06 +08:00
XRAY_FLAG(int, buffers_max, 128,
"The number of buffers to pre-allocate used by the profiling "
"implementation.")