Re: [PATCH 0/4] alloc_tag: Introduce selective tracing for MAP

[Suren Baghdasaryan]

On Thu, Sep 24, 2026 at 2:52 AM Hao Ge <hao.ge@xxxxxxxxx> 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