On Sun, 4 May 2025 11:41:56 +0200
Ingo Molnar [off-list ref] wrote:
* Steven Rostedt [off-list ref] wrote:
quoted
unwind_user: Add user space unwinding API
unwind_user: Add frame pointer support
unwind_user/x86: Enable frame pointer unwinding on x86
perf/x86: Rename and move get_segment_base() and make it global
unwind_user: Add compat mode frame pointer support
unwind_user/x86: Enable compat mode frame pointer unwinding on x86
unwind_user/deferred: Add unwind cache
What is the cost of 'caching' here? Will we double-buffer the tracing
data before it reaches its single primary tooling user, with no use of
any actual 'caching', which will be scenario in like 99.9% of the
everyday usecases when this facility is used?
I'm sorry, I may not understand the question here.
The cache doesn't add any extra buffer. The previous patch (Add unwind
deferred trace) allocates "entries" the first time a trace is done to
save the user stacktrace into the buffer. It will not free the entries
(until exit of the task) to save from having to allocate the entries
again.
If for some reason an interrupt happens while it is recording the trace
and the interrupt requests another trace, without the cache, it will do
the work of walking the user stack trace again.
The "cache" code, simply keeps information around to know that the
current trace is still valid, and that it doesn't need to do the work
of walking the user stack to produce the stack again.
quoted
unwind_user/deferred: Add deferred unwinding interface
unwind_user/deferred: Make unwind deferral requests NMI-safe
perf: Remove get_perf_callchain() init_nr argument
perf: Have get_perf_callchain() return NULL if crosstask and user are set
perf: Simplify get_perf_callchain() user logic
perf: Skip user unwind if the task is a kernel thread.
Please don't leave periods in titles.
OK, will fix.
Thanks for looking at this Ingo!
-- Steve