Thread (208 messages) 208 messages, 21 authors, 2024-02-29

Re: [PATCH v3 00/35] Memory allocation profiling

From: Kent Overstreet <kent.overstreet@linux.dev>
Date: 2024-02-14 15:01:28
Also in: cgroups, linux-arch, linux-doc, linux-fsdevel, linux-iommu, linux-mm, lkml

On Wed, Feb 14, 2024 at 03:46:33PM +0100, Michal Hocko wrote:
On Wed 14-02-24 01:20:20, Johannes Weiner wrote:
[...]
quoted
I agree we should discuss how the annotations are implemented on a
technical basis, but my take is that we need something like this.
I do not think there is any disagreement on usefulness of a better
memory allocation tracking. At least for me the primary problem is the
implementation. At LFSMM last year we have heard that existing tracing
infrastructure hasn't really been explored much. Cover letter doesn't
really talk much about those alternatives so it is really hard to
evaluate whether the proposed solution is indeed our best way to
approach this.
Michal, we covered this before.

To do this with tracing you'd have to build up data structures
separately, in userspace, that would mirror the allocator's data
structures; you would have to track every single allocation so that you
could match up the free event to the place it was allocated.

Even if it could be built, which I doubt, it'd be completely non viable
because the performance would be terrible.

Like I said, we covered all this before; if you're going to spend so
much time on these threads you really should be making a better attempt
at keeping up with what's been talked about.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help