This is an archive of the discontinued LLVM Phabricator instance.

[trace][intelpt] Support system-wide tracing [2] - Add a dummy --per-core-tracing option
ClosedPublic

Authored by wallace on Apr 28 2022, 3:13 PM.

Details

Summary

This updates the documentation of the gdb-remote protocol, as well as the help messages, to include the new --per-core-tracing option.
I made some renames to account for this new option

Diff Detail

Event Timeline

wallace created this revision.Apr 28 2022, 3:13 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 28 2022, 3:13 PM
wallace requested review of this revision.Apr 28 2022, 3:13 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 28 2022, 3:13 PM
wallace edited the summary of this revision. (Show Details)Apr 28 2022, 3:15 PM
jj10306 requested changes to this revision.May 2 2022, 8:20 AM

Before doing a complete review can you provide clarity on the decision to only support perCore for process wide (see my inline comment with my thoughts/questions)? Understanding this will potentially provide the answers to many other questions I was going to leave, so figured I'd ask it ahead of time (:

lldb/docs/lldb-gdb-remote.txt
369

Why do we only want this option for process tracing?
Per cpu tracing collects all trace data agnostic to a user specified process/thread, so why should this only be exposed for process wide? I think it makes more sense to decouple the perCoreTracing option from process/threads specific options entirely so it is its own option all together and cannot be used in conjunction with process/thread options.
If there is reason to not go down that route, we then should also add support for perCoreTracing with the thread tracing option, not just the process tracing option as I feel it doesn't make since to only expose this for process tracing since it's doing the same thing behind the scenes.

lldb/source/Plugins/Trace/intel-pt/CommandObjectTraceStartIntelPT.cpp
66

So now m_trace_buffer_size is the size of each trace buffer, regardless of the buffer is for a single thread or a single core?

This revision now requires changes to proceed.May 2 2022, 8:20 AM
wallace added inline comments.May 2 2022, 8:52 AM
lldb/docs/lldb-gdb-remote.txt
369

The reason is that if you want to trace a specific thread, it's actually much better to use single-buffer thread tracing than per cpu. You get full fidelity and no data loss in this mode. On the other hand, per cpu tracing is really useful in a thread-unbounded case where you are okay with having no data for unfrequent threads.
Per-core single-tracing is doable, but it's very impractical in the context of LLDB. However, if we ever need to implement it eventually, we for sure can refactor the code for that.

wallace added inline comments.May 2 2022, 9:00 AM
lldb/source/Plugins/Trace/intel-pt/CommandObjectTraceStartIntelPT.cpp
66

yep

wallace requested review of this revision.May 5 2022, 10:33 AM
jj10306 accepted this revision.May 8 2022, 3:06 PM
This revision is now accepted and ready to land.May 8 2022, 3:06 PM