On Tue 13-02-24 14:59:11, Suren Baghdasaryan wrote: > On Tue, Feb 13, 2024 at 2:50 PM Kent Overstreet > <kent.overstreet@xxxxxxxxx> wrote: > > > > On Tue, Feb 13, 2024 at 11:48:41PM +0100, David Hildenbrand wrote: [...] > > > If you think you can easily achieve what Michal requested without all that, > > > good. > > > > He requested something? > > Yes, a cleaner instrumentation. Nope, not really. You have indicated you want to target this version for the _next_ merge window without any acks, really. If you want to go forward with this then you should gain a support from the MM community at least. Why? Because the whole macro layering is adding maintenance cost for MM people. I have expressed why I absolutely hate the additional macro layer. We have been through similar layers of macros in other areas (not to mention page allocator interface itself) and it has _always_ turned out a bad idea long term. I do not see why this case should be any different. The whole kernel is moving to a dynamic tracing realm and now we are going to build a statically macro based tracing infrastructure which will need tweaking anytime real memory consumers are one layer up the existing macro infrastructure (do not forget quite a lot of allocations are in library functions) and/or we need to modify the allocator API in some way. Call me unimpressed! Now, I fully recognize that the solution doesn't really have to be perfect in order to be useful. Hence I never NAKed it even though I really _dislike_ the approach. I have expected you will grow the community support over time if this is indeed the only feasible approach but that is not reflected in the series posted here. If you find a support I will not stand in the way. > Unfortunately the cleanest one is not > possible until the compiler feature is developed and deployed. And it > still would require changes to the headers, so don't think it's worth > delaying the feature for years. I am pretty sure you have invested a non-trivial time into evaluating other ways, yet your cover letter is rather modest about any details: : - looked at alternate hooking methods. : There were suggestions on alternate methods (compiler attribute, : trampolines), but they wouldn't have made the patchset any cleaner : (we still need to have different function versions for accounting vs. no : accounting to control at which point in a call chain the accounting : happens), and they would have added a dependency on toolchain : support. First immediate question would be: What about page_owner? I do remember the runtime overhead being discussed but I do not really remember any actual numbers outside of artificial workloads. Has this been investigated? Is our stack unwinder the problem? Etc. Also what are the biggest obstacles to efficiently track allocations via our tracing infrastructure? Has this been investigated? What were conclusions? -- Michal Hocko SUSE Labs
