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

From: Suren Baghdasaryan

Date: Fri Jul 31 2026 - 17:06:43 EST


On Fri, Jul 31, 2026 at 6:37 PM Abhishek Bapat <abhishekbapat@xxxxxxxxxx> wrote:
>
> On Fri, Jul 31, 2026 at 10:25 AM Abhishek Bapat
> <abhishekbapat@xxxxxxxxxx> wrote:
> >
> > Hi Hao,
> >
> > Thanks for reviewing the v2 patch.
> >
> > >
> > > Hi Abhishek
> > >
> > >
> > > Thanks for the v2 patch.
> > >
> > >
> > > On 2026/7/31 07:48, 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.
> > > >
> > > > Resolve this ambiguity by exposing the active compression state by
> > > > adding a new read-only sysctl `vm.memprofiling_compressed` to output the
> > > > state.
> > >
> > >
> > > I think this should be vm.mem_profiling_compressed.
> > >
> > > Otherwise, you will need to adjust the procname for this new sysctl
> > > accordingly.
> > >
> > > Also, kindly add docs at the linked path.
> > >
> > > https://elixir.bootlin.com/linux/v7.2-rc4/source/Documentation/mm/allocation-profiling.rst#L33
> > >
> > >
> > Thanks for bringing this up, I didn't realize that I forgot the
> > underscore in the commit msg. I'll fix this in v3 and also add some
> > documentation about this.
> >
> > > > Signed-off-by: Abhishek Bapat <abhishekbapat@xxxxxxxxxx>
> > > > ---
> > > > mm/alloc_tag.c | 6 ++++++
> > > > 1 file changed, 6 insertions(+)
> > > >
> > > > diff --git a/mm/alloc_tag.c b/mm/alloc_tag.c
> > > > index 52aece27b00e..877068241f06 100644
> > > > --- a/mm/alloc_tag.c
> > > > +++ b/mm/alloc_tag.c
> > > > @@ -1303,6 +1303,12 @@ static const struct ctl_table memory_allocation_profiling_sysctls[] = {
> > > > .mode = 0644,
> > > > .proc_handler = proc_mem_profiling_handler,
> > > > },
> > > > + {
> > > > + .procname = "mem_profiling_compressed",
> > > > + .data = &mem_profiling_compressed,
> > > > + .mode = 0444,
> > > > + .proc_handler = proc_do_static_key,
> > > > + },
> > > > };
> > > >
> > >
> > >
> > > I think adding this sysctl alone won't be enough.
> > >
> > > If we set boot arg sysctl.vm.mem_profiling=1,compressed but profiling
> > > gets disabled due to insufficient page flags,
> > >
> > > this sysctl will still report 1 (compression enabled) even though
> > > profiling was shut down.
> > >
> > > To verify this behavior, I have set up a test environment locally as
> > > shown below:
> > >
> > >
> > > [ 0.265503] 4046 allocation tags cannot be references using 5
> > > available page flag bits. Memory allocation profiling is disabled!
> > >
> > > [root@localhost ~]# cat /proc/sys/vm/mem_profiling_compressed
> > > 1
> > > [root@localhost ~]#
> > >
> > >
> > > I'm unsure whether we should initialize this sysctl when profiling gets
> > > disabled at boot.
> > > If we do, we should set mem_profiling_compressed to false in
> > > shutdown_mem_profiling.
> >
> > I think the way it currently works is, compression can only be toggled
> > at boot time. The new sysctl my patch introduces is read-only. Based
> > on the current behaviour, if compression is enabled, and profiling is
> > toggled off and then on again, it will be toggled on with compression
> > enabled as long as we're in the same boot session. I don't want to
> > include changing this behaviour in the scope of this patch. I want to
> > limit the scope of this patch only to expose the current state to the
> > userspace, hope that makes sense.
> >
>
> I reread what you'd mentioned and believe I originally misunderstood
> your point. You rightly pointed out the subtle bug where the
> compression state is left desynchronized if compression was unable to
> be turned on due to lack of page_flag bits. I acknowledge your comment
> and will change this behaviour in the v3 patch to toggle the
> compression state to "false" if this happens. Thanks for bringing this
> up and I apologize for my previous misunderstanding.

Well, if profiling got disabled then it doesn't matter whether
compression was requested or not. The profiling is not active anyway,
right?
IMO if would be less confusing if we let mem_profiling_compressed
reflect what the system was configured to do. If that configuration
was impossible and profiling got disabled, the userspace can detect
that by reading mem_profiling sysctrl. As Hao mentioned, this should
be clearly documented in the docs.

>
> > >
> > >
> > > Thanks
> > >
> > > Best Regards
> > >
> > > Hao
> > >
> > >
> > > > static void __init sysctl_init(void)
> > > >
> > > > base-commit: 2ed26e8a624f41887d64e2e37a2f6ab36a118d1f
> >
> > I'll also wait for Suren's comments before sending out a v3 patch.
> >
> > Thanks,
> > Abhishek.