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)

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

-- 
2.54.0.545.g6539524ca2-goog

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@linux.dev/

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
>

On Wed, May 6, 2026 at 1:45 AM Hao Ge <hao.ge@linux.dev> wrote:
>
> 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@linux.dev/
>
> 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?

Hi Hao,
Sorry for the delay, I was travelling for LSFMM and missed a bunch of emails.
Yes, we are planning to upstream alloctop tool
(https://android-review.googlesource.com/c/platform/system/memory/libmeminfo/+/3431860)
and now with ioctl support it becomes more relevant. Once this
patchset is merged, we will prepare the tool and post the patch.
Thanks,
Suren.


>
> 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
> >

On 2026/5/13 03:58, Suren Baghdasaryan wrote:
> On Wed, May 6, 2026 at 1:45 AM Hao Ge<hao.ge@linux.dev>  wrote:
>> 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@linux.dev/
>>
>> 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?
> Hi Hao,
> Sorry for the delay, I was travelling for LSFMM and missed a bunch of emails.
> Yes, we are planning to upstream alloctop tool
> (https://android-review.googlesource.com/c/platform/system/memory/libmeminfo/+/3431860)
> and now with ioctl support it becomes more relevant. Once this
> patchset is merged, we will prepare the tool and post the patch.
> Thanks,
> Suren.

Hi Suren

Thanks for the info! The alloctop tool looks great, looking forward to it.

I'd be happy to help review or test it once it's posted.

Best Regards

Hao