| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[trace][intelpt] Support system-wide tracing [14] - Decode per cpu This is the final functional patch to support intel pt decoding per cpu. It works by doing the following: - First, all context switches are split by tid and sorted in order. This produces a list of continuous executes per thread per core. - Then, all intel pt subtraces are split by PSB boundaries and assigned to individual thread continuous executions on the same core by doing simple TSC-based comparisons. - With this, we have, per thread, a sorted list of continuous executions each one with a list of intel pt subtraces. Up to this point, this is really fast because no instructions were actually decoded. - Then, each thread can be decoded by traversing their continuous executions and intel pt subtraces. An advantage of having these continuous executions is that we can identify if a continuous exexecution doesn't have intel pt data, and thus has a gap in it. We can later to more sofisticated comparisons to identify if within a continuous execution there are gaps. I'm adding a test as well. Differential Revision: https://reviews.llvm.org/D126394 | 4 年前 | |
[trace][intelpt] Support system-wide tracing [14] - Decode per cpu This is the final functional patch to support intel pt decoding per cpu. It works by doing the following: - First, all context switches are split by tid and sorted in order. This produces a list of continuous executes per thread per core. - Then, all intel pt subtraces are split by PSB boundaries and assigned to individual thread continuous executions on the same core by doing simple TSC-based comparisons. - With this, we have, per thread, a sorted list of continuous executions each one with a list of intel pt subtraces. Up to this point, this is really fast because no instructions were actually decoded. - Then, each thread can be decoded by traversing their continuous executions and intel pt subtraces. An advantage of having these continuous executions is that we can identify if a continuous exexecution doesn't have intel pt data, and thus has a gap in it. We can later to more sofisticated comparisons to identify if within a continuous execution there are gaps. I'm adding a test as well. Differential Revision: https://reviews.llvm.org/D126394 | 4 年前 | |
[trace][intelpt] Support system-wide tracing [14] - Decode per cpu This is the final functional patch to support intel pt decoding per cpu. It works by doing the following: - First, all context switches are split by tid and sorted in order. This produces a list of continuous executes per thread per core. - Then, all intel pt subtraces are split by PSB boundaries and assigned to individual thread continuous executions on the same core by doing simple TSC-based comparisons. - With this, we have, per thread, a sorted list of continuous executions each one with a list of intel pt subtraces. Up to this point, this is really fast because no instructions were actually decoded. - Then, each thread can be decoded by traversing their continuous executions and intel pt subtraces. An advantage of having these continuous executions is that we can identify if a continuous exexecution doesn't have intel pt data, and thus has a gap in it. We can later to more sofisticated comparisons to identify if within a continuous execution there are gaps. I'm adding a test as well. Differential Revision: https://reviews.llvm.org/D126394 | 4 年前 | |
[trace][intelpt] Support system-wide tracing [20] - Rename some fields in the schema As discusses offline with @jj10305, we are updating some naming used throughout the code, specially in the json schema - traceBuffer -> iptTrace - core -> cpu Differential Revision: https://reviews.llvm.org/D127817 | 4 年前 | |
[trace][intelpt] Support system-wide tracing [20] - Rename some fields in the schema As discusses offline with @jj10305, we are updating some naming used throughout the code, specially in the json schema - traceBuffer -> iptTrace - core -> cpu Differential Revision: https://reviews.llvm.org/D127817 | 4 年前 | |
[trace][intelpt] Support system-wide tracing [21] - Support long numbers in JSON llvm's JSON parser supports 64 bit integers, but other tools like the ones written in JS don't support numbers that big, so we need to represent these possibly big numbers as a string. This diff uses that to represent addresses and tsc zero. The former is printed in hex for and the latter in decimal string form. The schema was updated mentioning that. Besides that, I fixed some remaining issues and now all test pass. Before I wasn't running all tests because for some reason my computer reverted perf_paranoid to 1. Differential Revision: https://reviews.llvm.org/D127819 | 4 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 |