Messages in this thread | | | From | Suren Baghdasaryan <> | Date | Wed, 3 May 2023 10:40:42 -0700 | Subject | Re: [PATCH 00/40] Memory allocation profiling |
| |
On Wed, May 3, 2023 at 9:28 AM Steven Rostedt <rostedt@goodmis.org> wrote: > > On Wed, 3 May 2023 08:09:28 -0700 > Suren Baghdasaryan <surenb@google.com> wrote: > > > There is another issue, which I think can be solved in a smart way but > > will either affect performance or would require more memory. With the > > tracing approach we don't know beforehand how many individual > > allocation sites exist, so we have to allocate code tags (or similar > > structures for counting) at runtime vs compile time. We can be smart > > about it and allocate in batches or even preallocate more than we need > > beforehand but, as I said, it will require some kind of compromise. > > This approach is actually quite common, especially since tagging every > instance is usually overkill, as if you trace function calls in a running > kernel, you will find that only a small percentage of the kernel ever > executes. It's possible that you will be allocating a lot of tags that will > never be used. If run time allocation is possible, that is usually the > better approach.
True but the memory overhead should not be prohibitive here. As a ballpark number, on my machine I see there are 4838 individual allocation locations and each codetag structure is 32 bytes, so that's 152KB.
> > -- Steve
| |