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

[Abhishek Bapat]

On Thu, Jul 30, 2026 at 12:49 PM Suren Baghdasaryan <surenb@xxxxxxxxxx> wrote:
>
> 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.
>
>
Hi Suren,

Sure, if there's consensus that /proc/allocinfo is not the right
place, I could share a v2 patch that instead exposes a read-only file
called something like /proc/sys/vm/mem_profiling_compressed to expose
the value of the compressed boolean. Does that work?

Thanks,
Abhishek.

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