Re: [PATCH 0/6] alloc_tag: introduce IOCTL-based filtering for MAP

[Hao Ge]

Hi Abhishek and Suren


On 2026/5/5 07:36, Abhishek Bapat wrote:
> Currently, memory allocation profiling data is primarily exposed through
> /proc/allocinfo. While useful for manual inspection, this text-based
> interface poses challenges for production monitoring and large-scale
> analysis:
>
> 1. Userspace must parse large amounts of text to extract specific
> fields.
> 2. To find specific tags, userspace must read the entire dataset,
> requiring many context switches and high data copying.
> 3. The kernel currently aggregates per-CPU counters for every allocation
> size, even those the user intends to filter out immediately.
>
> This series introduces a new IOCTL-based binary interface for allocinfo
> that supports kernel-side filtering. By allowing the user to specify a
> filter mask, we significantly reduce the work performed in-kernel and
> the amount of data transferred to userspace.
>
> Performance measurements were conducted on an Intel Xeon Platinum 8481C
> (224 CPUs) with caches dropped before each run.
>
> The IOCTL mechanism shows a ~20x performance improvement for
> filtered queries. The kernel avoids the expensive per-CPU counter
> aggregation (alloc_tag_read) for any tags that fail the initial string
> or location filters.
>
> Scenario 1: Specific File Filtering (arch/x86/events/rapl.c)
> 1. Traditional (cat /proc/allocinfo | grep): 22ms (sys)
> 2. IOCTL Interface: 1ms (sys)
>
> Scenario 2: Compound Filtering (Filename + Size)
> 1. Traditional: (cat ... | grep | awk): 21ms (sys)
> 2. IOCTL Interface: 1ms (sys)
>
> Scenario 3: Size-Based Filtering (min_size = 1MB)
> 1. Traditional: (cat ... | awk): 21ms (sys)
> 2. IOCTL Interface: 14ms (sys)

What a coincidence! I was just about to send an email to Suren

asking about plans for upstreaming a filtering tool for /proc/allocinfo,

and then I came across this patchset.

I have been following and using memory allocation profiling since

it was first introduced. It has been very helpful for our memory

analysis by providing clear visibility into allocation data. However,

we have always wanted a tool to efficiently filter this data to get

exactly what we need, so I previously developed a userspace tool [1]

to help with that.

[1] https://lore.kernel.org/all/20250106112103.25401-1-hao.ge@xxxxxxxxx/

So this patchset provides efficient filtering of allocinfo data via ioctl.

Would the next step be to develop a general-purpose tool under

tools/mm that leverages these ioctls instead of parsing /proc/allocinfo 
text output?

Thanks

Best Regards

Hao

> Abhishek Bapat (5):
>    alloc_tag: add ioctl filters to /proc/allocinfo
>    alloc_tag: add size-based filtering to ioctl
>    alloc_tag: add accuracy based filtering to ioctl
>    kselftest: alloc_tag: add kselftest for ioctl interface
>    kselftest: alloc_tag: extend the allocinfo ioctl kselftest
>
> Suren Baghdasaryan (1):
>    alloc_tag: add ioctl to /proc/allocinfo
>
>   .../userspace-api/ioctl/ioctl-number.rst      |   2 +
>   include/linux/codetag.h                       |   1 +
>   include/uapi/linux/alloc_tag.h                |  87 +++
>   lib/alloc_tag.c                               | 249 ++++++++-
>   lib/codetag.c                                 |  11 +
>   tools/testing/selftests/alloc_tag/Makefile    |   9 +
>   .../alloc_tag/allocinfo_ioctl_test.c          | 508 ++++++++++++++++++
>   7 files changed, 865 insertions(+), 2 deletions(-)
>   create mode 100644 include/uapi/linux/alloc_tag.h
>   create mode 100644 tools/testing/selftests/alloc_tag/Makefile
>   create mode 100644 tools/testing/selftests/alloc_tag/allocinfo_ioctl_test.c