Skip to content

Conversation

nsavoire
Copy link
Contributor

@nsavoire nsavoire commented Sep 1, 2025

If a zero cache size is provided to the tracehandler, the cache is completely disabled.

Rationale

Tracehandler cache is using a large amount of memory for almost no CPU benefit (disabling it did not result in a noticeable CPU increase).

If a zero size is provided for the tracehandler cache, the cache will not be
created.
@nsavoire nsavoire requested review from a team as code owners September 1, 2025 08:52
@fabled
Copy link
Contributor

fabled commented Sep 1, 2025

I am also working to convert the trace cache from trace to frame based thing. It should improve its usefulness, and also allow smaller sizes to be more efficient.

Perhaps it still is beneficial to allow disabling it if needed.

@florianl
Copy link
Contributor

florianl commented Sep 2, 2025

tracehandler used to be an essential tool for the time, when counters where increased and reported for repeated stacks. With the current design, this is no longer the case. For on-CPU profiling, we also see hardly repeated stacks (usually there are differences in the leaf frames). Only for off-CPU profiling and [u,k]probe profiling, we could benefit from tracehandler and its caching.
With a focus on on-CPU profiling, maybe it is best to remove tracehandler as intermediate step and reduce also the complexity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants