perf(memtrack): stop capturing stacks on free - #558
not-matthias wants to merge 1 commit into
Conversation
 |
Memory flamegraphs only attribute allocations: the platform unwinds free stacks and never reads the result. Capturing them doubled the per-event probe cost, the stack ring traffic, and the archive's stack bytes. The Free event no longer carries a stack_hash. Artifacts from older memtrack versions that still have the field decode unchanged. Refs COD-3703
96e3091 to
6a35299
Compare
Merging this PR will not alter performance
|
Comments Outside DiffThese findings could not be posted inline.
|
| @@ -60,6 +60,9 @@ pub enum MemtrackEventKind { | |||
| stack_hash: u64, | |||
| }, | |||
| Free { | |||
There was a problem hiding this comment.
Did we release this already? Else outright delete it IMO, if it's just dev traces. WDYT? Else keep it like this
There was a problem hiding this comment.
No release yet. So good point. I'll drop it.
2 participants
Why
Memory flamegraphs only attribute allocations. The platform's
memtrack-parserunwinds stacks attached toFreeevents and caches the callchain, but only allocation samples are folded, so free stacks are never read.With stack capture on by default, every
free()still paid the full capture: an 8 KiB user-stack copy, the FNV hash,bpf_get_stackid, and (since exact-hash dedup is ~0% effective) a full record into the stack ring. That is roughly half of all captures.What
freeuprobe no longer callscapture_stack;submit_free_eventdrops the hash.MemtrackEventKind::Freeis a unit variant. The serialized form is unchanged (stack_hashwas already skipped when zero), and artifacts written by older memtrack versions with astack_hashon frees still decode (covered bylegacy_free_with_stack_hash_decodes).Freewithout thehas_stackflag.Expected effect
About half the stack captures, stack ring writes, encode CPU, and archive stack bytes on allocation-heavy benchmarks; less unwinding work in callgraph generation. To be measured on the platform memory shards (COD-3703).