On Sun, 7 May 2023 13:20:55 -0400 Kent Overstreet <kent.overstreet@xxxxxxxxx> wrote: > On Thu, May 04, 2023 at 11:07:22AM +0200, Michal Hocko wrote: > > No. I am mostly concerned about the _maintenance_ overhead. For the > > bare tracking (without profiling and thus stack traces) only those > > allocations that are directly inlined into the consumer are really > > of any use. That increases the code impact of the tracing because any > > relevant allocation location has to go through the micro surgery. > > > > e.g. is it really interesting to know that there is a likely memory > > leak in seq_file proper doing and allocation? No as it is the specific > > implementation using seq_file that is leaking most likely. There are > > other examples like that See? > > So this is a rather strange usage of "maintenance overhead" :) > > But it's something we thought of. If we had to plumb around a _RET_IP_ > parameter, or a codetag pointer, it would be a hassle annotating the > correct callsite. > > Instead, alloc_hooks() wraps a memory allocation function and stashes a > pointer to a codetag in task_struct for use by the core slub/buddy > allocator code. > > That means that in your example, to move tracking to a given seq_file > function, we just: > - hook the seq_file function with alloc_hooks Thank you. That's exactly what I was trying to point out. So you hook seq_buf_alloc(), just to find out it's called from traverse(), which is not very helpful either. So, you hook traverse(), which sounds quite generic. Yes, you're lucky, because it is a static function, and the identifier is not actually used anywhere else (right now), but each time you want to hook something, you must make sure it does not conflict with any other identifier in the kernel... Petr T
