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

On Fri, Jul 31, 2026 at 2:10 PM Abhishek Bapat <[email protected]> wrote:
>
> On Fri, Jul 31, 2026 at 2:04 PM Suren Baghdasaryan <[email protected]> wrote:
> >
> > On Fri, Jul 31, 2026 at 6:37 PM Abhishek Bapat <[email protected]> wrote:
> > >
> > > On Fri, Jul 31, 2026 at 10:25 AM Abhishek Bapat
> > > <[email protected]> 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 <[email protected]>
> > > > > > ---
> > > > > >   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.
> >
> So, IIUC, you're suggesting that I not change the kernel behaviour for
> the edge case Hao brought up and simply expose the boolean value
> through the read-only sysctl. Right?

Correct. And please clearly document that mem_profiling_compressed
reflects how the system was configured. In contrast, mem_profiling
reflects the current state of profiling, which might be different from
how it was configured originally (might have been disabled later by
the system or by the user).

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