Re: [PATCH] alloc_tag: expose profiling and compression states in /proc/allocinfo

[Suren Baghdasaryan]

On Thu, Jul 30, 2026 at 10:57 AM Abhishek Bapat
<abhishekbapat@xxxxxxxxxx> wrote:
>
> Hi Hao,
>
> Thanks for your review, however, I'd like to disagree with your
> points. Replies in line:
>
> On Wed, Jul 29, 2026 at 7:23 PM Hao Ge <hao.ge@xxxxxxxxx> wrote:
> >
> > Hi Abhishek
> >
> >
> > Thanks for your patch.
> >
> >
> > On 2026/7/30 06:49, Abhishek Bapat wrote:
> > > Currently, userspace has limited visibility into the exact active
> > > runtime state of memory allocation profiling and its page extension
> > > compression ('sysctl.vm.mem_profiling={0|1|never}[,compressed]').
> > >
> > > While reading the sysctl provides basic on/off status, it is currently
> > > impossible for userspace to natively determine whether page-tag
> > > compression was successfully enabled without scraping dmesg boot logs.
> > > Furthermore, since /proc/allocinfo remains in the procfs filesystem even
> > > after profiling is dynamically disabled at runtime, simply checking for
> > > the file's presence does not reliably indicate if the allocation
> > > tracking hooks are actively running.
> > >
> > > Resolve this ambiguity by appending the active state directly into the
> > > header of /proc/allocinfo.
> >
> >
> > It's not obvious to me why userspace would need this state.
> >
> >
> > Suppose userspace reads mem_alloc_profiling_enabled as disabled, then
> > the profiling
> >
> > gets enabled later. All allocations generated during that intermediate
> > window are lost.
> >
> > When users later cat /proc/allocinfo and see the enabled state, will
> > they mistakenly take
> >
> > the output as a complete, accurate record?
> >
>
> Currently, userspace has no mechanism to determine the actual internal
> state of mem_alloc_profiling, meaning users are forced to make
> assumptions regardless.
>
> By exposing the explicit state, this patch allows userspace to query
> and validate the state concretely rather than guessing. If the state
> changes, userspace can immediately detect this and react accordingly
> (for instance by invalidating and / or refreshing its view). Rather
> than introducing unsafe assumptions, this brings a clear, testable and
> net-positive improvement over the current opaque behaviour.
>
> >
> > I'm also unclear what userspace would do with the compression state;
> >
> > this is just an internal implementation detail of memory profiling.
> >
> > Put another way, personally I'd prefer /proc/allocinfo to stay lean and
> >
> > avoid exposing too many internal implementation details to userspace.
> >
> > Unless users intend to dig deep into how memory profiling works, these
> > extra details
> >
> > will likely only confuse them — most don't care about internals at all.
> >
> > It's similar to how we use APIs: we only care about what an API achieves,
> >
> > not its underlying implementation.
> >
> >
> > Could you share the concrete use cases for exposing these states to
> > userspace?
> >
> In large scale production environments (such as our deployments at
> Google), we can only afford to run memory allocation profiling when
> compression is enabled, as the overhead of running with compression
> disabled is too high for production workloads.
>
> Currently, there is no way to write an automated regression test to
> validate that compression is active. Exposing this configuration state
> in /proc/allocinfo provides a clean, concrete interface to write
> regression tests that verify and enforce this constraint in
> production.
>
> Hope this helps clarify the intent behind these changes.

Hi Folks,
Thinking about these states, I tend to agree with Hao that compression
state is somewhat internal information that most users should not care
about. So, adding that state into /proc/allocinfo, which contains the
data user cares about does not seem ideal. Maybe we can expose that
via some other interface, like /proc/sys/vm/ or debugfs?
I also just realized that profiling enabled state can be read from
/proc/sys/vm/mem_profiling, so we don't really need anything extra for
it. Would you agree?
Thanks,
Suren.




>
> Thanks,
> Abhishek.
>
> >
> > Thanks
> >
> > Best Regards
> >
> > Hao
> >
> >
> > > Signed-off-by: Abhishek Bapat <abhishekbapat@xxxxxxxxxx>
> > > ---
> > >   mm/alloc_tag.c | 6 +++++-
> > >   1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/mm/alloc_tag.c b/mm/alloc_tag.c
> > > index 52aece27b00e..89ec2c6ce57a 100644
> > > --- a/mm/alloc_tag.c
> > > +++ b/mm/alloc_tag.c
> > > @@ -108,7 +108,11 @@ static void allocinfo_stop(struct seq_file *m, void *arg)
> > >   static void print_allocinfo_header(struct seq_buf *buf)
> > >   {
> > >       /* Output format version, so we can change it. */
> > > -     seq_buf_printf(buf, "allocinfo - version: 2.0\n");
> > > +     seq_buf_printf(buf, "allocinfo - version: 2.1\n");
> > > +     seq_buf_printf(buf, "# Profiling: %s\n",
> > > +                    mem_alloc_profiling_enabled() ? "Enabled" : "Disabled");
> > > +     seq_buf_printf(buf, "# Compression: %s\n",
> > > +                    static_key_enabled(&mem_profiling_compressed) ? "Enabled" : "Disabled");
> > >       seq_buf_printf(buf, "#     <size>  <calls> <tag info>\n");
> > >   }
> > >
> > >
> > > base-commit: c73b725a57f276a3702ca213bde78fca029bc619