This is an archive of the discontinued LLVM Phabricator instance.

[trace][intelpt] Support system-wide tracing [3] - Refactor IntelPTThreadTrace
ClosedPublic

Authored by wallace on Apr 28 2022, 5:20 PM.

Details

Summary

I'm refactoring IntelPTThreadTrace into IntelPTSingleBufferTrace so that it can
both single threads or single cores. In this diff I'm basically renaming the
class, moving it to its own file, and removing all the pieces that are not used
along with some basic cleanup.

Besides that, as we'll soon support per-core trace buffer, I'm renaming the
data kind "threadTraceBuffer" to "traceBuffer".

Diff Detail

Event Timeline

wallace created this revision.Apr 28 2022, 5:20 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 28 2022, 5:20 PM
Herald added a subscriber: mgorny. · View Herald Transcript
wallace requested review of this revision.Apr 28 2022, 5:20 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 28 2022, 5:20 PM
wallace edited the summary of this revision. (Show Details)Apr 28 2022, 5:21 PM
jj10306 requested changes to this revision.May 2 2022, 8:47 AM
jj10306 added inline comments.
lldb/docs/lldb-gdb-remote.txt
498

If perCore tracing is enabled, how will this packet work since currently it requires a tid, but in perCore mode the trace data will contain all activity on that core, not just the specified thread?

lldb/source/Plugins/Process/Linux/IntelPTCollector.h
136

update doc since this is no longer tied to thread's traces

lldb/source/Plugins/Process/Linux/IntelPTSingleBufferTrace.cpp
293–299

The PerfEvent logic will need to be updated to support per CPU or per thread as it currently only supports per thread

lldb/source/Plugins/Process/Linux/IntelPTSingleBufferTrace.h
2

nit: thoughts on the name IntelPTTraceBuffer instead of IntelPTSingleBufferTrace? The current name is a bit wordy imo

42–49

Shouldn't this structure be general and have no notion of a tid since it could represent the buffer of a single thread or the buffer of a single CPU?
The way I see it, this structure simply wraps the buffer of a specific perf_event but has no notion of if it's for a specific tid or cpu.
Then you could have two subclasses, one for thread one for cpu, that inherit from this and have the additional context about the buffer. The inheritance may be overkill, but point I'm trying to make is that this structure should be agnostic to what "unit's" (thread or cpu) trace data it contains

This revision now requires changes to proceed.May 2 2022, 8:47 AM
wallace added inline comments.May 2 2022, 9:40 AM
lldb/docs/lldb-gdb-remote.txt
498

the jLLDBGetBinaryData packet has, for example, an optional tid argument that indicates the data correspond to a specific tid. I'll add a new optional parameter called core_id, so that we can associate a data chunk with a core_id

lldb/source/Plugins/Process/Linux/IntelPTCollector.h
136

good catch!

lldb/source/Plugins/Process/Linux/IntelPTSingleBufferTrace.cpp
293–299

yes, definitely

lldb/source/Plugins/Process/Linux/IntelPTSingleBufferTrace.h
2

this is intentional because the next file will be IntelPTMultiCoreTrace.h.

I also don't want to call this IntelPTTraceBuffer because it'll eventually have itrace data so the object won't be just a trace buffer.

But I'm open to any suggestions because I also don't like super verbose names

42–49

what I was thinking is to change this in a later diff to be like

Start(const TraceIntelPTStartRequest &request, Optional<lldb::tid_t> tid, Optional<int> core_id);

which seems to me generic enough for all possible use cases. LLDB couldn't support cgroups, so we are limited to tids and core_ids. With this, it seems to me that having two child classes it's a little bit too much because the only difference are just two lines of code where we specify the perf_event configuration for tid and core_id.

But if you insist in the clarify of the subclasses, I for sure can do it that way.

wallace added inline comments.May 2 2022, 10:00 AM
lldb/source/Plugins/Process/Linux/IntelPTCollector.h
136

actually the comment is right because this collection is in fact for threads

wallace updated this revision to Diff 426546.May 2 2022, 5:14 PM

update test

jj10306 accepted this revision.May 8 2022, 3:17 PM

I'm assuming the changes to make the single buffer trace class generic for threads and cpu buffers is done in the next diff so stamping this, feel free to update with those changes if that is not the case

lldb/source/Plugins/Process/Linux/IntelPTSingleBufferTrace.h
42–49

What you suggested makes sense, do you plan make this change in this diff or is this in one of the future ones?

This revision is now accepted and ready to land.May 8 2022, 3:17 PM
wallace added inline comments.May 9 2022, 3:50 PM
lldb/source/Plugins/Process/Linux/IntelPTSingleBufferTrace.h
42–49

it's in a later diff

lldb/source/Utility/TraceIntelPTGDBRemotePackets.cpp