On 5/10/21 6:46 AM, Andrew Morton wrote: > On Wed, 14 Apr 2021 18:34:34 +0200 glittao@xxxxxxxxx wrote: > >> Many stack traces are similar so there are many similar arrays. >> Stackdepot saves each unique stack only once. >> >> Replace field addrs in struct track with depot_stack_handle_t handle. >> Use stackdepot to save stack trace. >> >> The benefits are smaller memory overhead and possibility to aggregate >> per-cache statistics in the future using the stackdepot handle >> instead of matching stacks manually. > > Which tree was this prepared against? 5.12's kmem_obj_info() is > significantly different from the version you were working on. It was based on -next at the time of submission, which contained patch in Paul's tree that expands kmem_obj_info to print also free call stack [1] so that also needs to be switched to stackdepot to work. > Please take a look, redo, retest and resend? Thanks. I expected [1] to be in 5.13-rc1, but as Paul explained to me, it's queued for 5.14. So if we (Oliver) rebase on current -next, can you queue it in the section of mmotm series that goes after -next? Vlastimil [1] https://lore.kernel.org/linux-arm-kernel/1615891032-29160-2-git-send-email-maninder1.s@xxxxxxxxxxx/
