On Mon, 6 Jul 2026 14:31:54 +0800 Li Pengfei <[email protected]> wrote:
> From: Pengfei Li <[email protected]> > > Hi Steven, Masami, > > Gentle ping on this v4 series now that the 7.2 merge window has settled. > > I'd especially value a quick steer on the two design questions from the > cover letter, since they shape how I respin: > > 1. Eager vs lazy allocation of the element pool (~8 MB at the default > bits=14 when CONFIG_FTRACE_STACKMAP=y, whether or not userspace ever > enables the option). Is eager allocation acceptable, or should v5 > switch to lazy allocation on the first 'echo 1 > options/stackmap'? > > 2. Whether to introduce the stack_map_bin binary interface now, or ship > the text stack_map interface first and add the binary export once > trace-cmd / libtraceevent integration is designed. > > Happy to respin in either direction. Full series for reference: > > https://lore.kernel.org/all/[email protected]/ Sorry for the late reply. I just started a new job (on 6/15) and spent the first two weeks focused on that. I'm just catching up now. Note, I tried out this patch set with function tracing on lock functions: trace-cmd start -p function -O stackmap --func-stack -l '*lock*' And wow! it grows pretty quickly # cat /sys/kernel/tracing/stack_map | wc 326593 708742 10979376 Anyway, I do like the idea and I may even use this to help do user space stack traces. But I will have to take a deeper dive into it, which I will hopefully have some time next week to do so. But if not next week, perhaps within the next month. I just letting you know that I'm not ignoring you. I'm just a bit behind. Thanks, -- Steve
