On Thu, Sep 24, 2026 at 2:52 AM Hao Ge <[email protected]> wrote: > > Hi Abhishek > > Thanks for your patch. > > On 2026/9/22 05:26, Abhishek Bapat wrote: > > The existing memory allocation profiling (MAP) tool accurately maintains > > aggregate counters for overall memory accounting. However, relying > > purely on aggregated counters restrics the visibility needed for > > targeted debugging. > > > > This patch series integrates three new tracepoints (alloc_tag_hit, > > alloc_tag_mem_alloced and alloc_tag_mem_freed) directly into the > > alloc_hooks_tag fast path. > > > > Enabling trace events globally for all allocations introduces a severe > > baseline overhead. To limit the performance overhead, we let the admin > > select specific allocations to be traced. > > > > A new IOCTL is introduced to allow privileged users to determine which > > allocation tags need tracing enabled. The IOCTL utilizes the > > pre-existing filtering mechanism to specify the allocation tags to > > enable tracing on. > > > > I think this cover‑letter could go into more detail. > Also, the cover‑letter doesn't include any how‑to‑use. > > Looking over this series, it seems you expect users to first call > ALLOCINFO_IOC_GET_AT to obtain a tag, then pass that tag into > ALLOCINFO_IOC_TOGGLE_TRACE. > > This behaviour is not reflected in the existing cover‑letter. > Before reading the code, I assumed I could just pass a module > name to trace all allocations from that module. After going > through the implementation, that turns out not to be the case. > > Because patch 2 enforces a full mask requirement for the filter. > > struct allocinfo_filter filter = { > .mask = ALLOCINFO_FILTER_MASK_MODNAME | > ALLOCINFO_FILTER_MASK_FUNCTION | > ALLOCINFO_FILTER_MASK_FILENAME | > ALLOCINFO_FILTER_MASK_LINENO, > .fields = params.fields, > }; > > So to trace all allocations from an entire module, users have to combine > ALLOCINFO_IOC_GET_AT, ALLOCINFO_IOC_GET_NEXT and ALLOCINFO_IOC_TOGGLE_TRACE > together. > > I have no strong objections if this is the intended design. > That said, we should settle on the expected usage model up‑front.
Hmm, I don't see why we should limit how users filter tags for tracing. We should not enforce them to filter on all available attributes. I think it's easy to fix by adding the filter mask to allocinfo_toggle_traces. > > Having corresponding Documentation would also be quite helpful. That way when > others > ask how to work with this feature, we can point them to existing written > material. > > https://elixir.bootlin.com/linux/v7.3-rc3/source/Documentation/mm/allocation-profiling.rst > > Thanks > Best Regards > Hao > > > Abhishek Bapat (4): > > alloc_tag: Add trace events for tracing allocations > > alloc_tag: Introduce IOCTLs to toggle allocation tracepoints > > alloc_tag: extend allocinfo_filter to support tracing queries > > alloc_tag: add a test for trace state toggle and filtering > > > > MAINTAINERS | 1 + > > include/linux/alloc_tag.h | 94 +++++++++--- > > include/linux/codetag.h | 5 +- > > include/trace/events/alloc_tag.h | 122 +++++++++++++++ > > include/uapi/linux/alloc_tag.h | 17 ++- > > mm/alloc_tag.c | 142 +++++++++++++++++- > > .../alloc_tag/allocinfo_ioctl_test.c | 111 +++++++++++++- > > 7 files changed, 462 insertions(+), 30 deletions(-) > > create mode 100644 include/trace/events/alloc_tag.h > > > > > > base-commit: 8d61431ed2607386b427752505379536eb634ce8
