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

[Hao Ge]

On 2026/5/13 03:58, Suren Baghdasaryan wrote:
> On Wed, May 6, 2026 at 1:45 AM Hao Ge<hao.ge@xxxxxxxxx>  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@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?
> 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