Re: [PATCH v3] alloc_tag: expose profiling and compression states

On Tue, Aug 4, 2026 at 10:28 AM Abhishek Bapat <[email protected]> wrote:
>
> On Mon, Aug 3, 2026 at 9:14 PM Hao Ge <[email protected]> wrote:
> >
> >
> > On 2026/8/4 10:15, Hao Ge wrote:
> > > Hi Abhishek
> > >
> > >
> > > Subject says "profiling and compression states", but this
> > >
> > > patch only adds the compression sysctl. The profiling state was
> > >
> > > already exposed via mem_profiling and is untouched here.
> > >
> > > I think we should make this more precise, like:
> > >
> > > alloc_tag: expose boot-time compression configuration
> > >
> > >
> > > On 2026/8/4 05:54, 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]').
> > >
> > >
> > > Profiling state is already readable via mem_profiling. The gap is
> > >
> > > only compression. Also, as we discussed, this sysctl reports
> > >
> > > what the user requested at boot rather than the actual runtime state.
> > >
> > >
> > >> 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.mem_profiling_compressed` to output
> > >> the
> > >> state.
> > >>
> > >> v3 change:
> > >> - Added documentation about the behaviour details of the new sysctl.
> > >>
> > >> v2 change:
> > >> - Moved from displaying the state in /proc/allocinfo to a new read-only
> > >> sysctl.
> > >
> > >
> > > As this is a standalone patch, please put the v2/v3 changelog below
> > > the --- line
> > >
> > > instead of inside the commit message.
> > >
> > >
> > > Thanks
> > >
> > > Best Regards
> > >
> > > Hao
> > >
> > >
> > >> Signed-off-by: Abhishek Bapat <[email protected]>
> > >> ---
> > >>   Documentation/mm/allocation-profiling.rst | 13 +++++++++++++
> > >>   mm/alloc_tag.c                            |  6 ++++++
> > >>   2 files changed, 19 insertions(+)
> > >>
> > >> diff --git a/Documentation/mm/allocation-profiling.rst
> > >> b/Documentation/mm/allocation-profiling.rst
> > >> index c3a28467955f..3ad1e9aacb9a 100644
> > >> --- a/Documentation/mm/allocation-profiling.rst
> > >> +++ b/Documentation/mm/allocation-profiling.rst
> > >> @@ -43,6 +43,19 @@ sysctl:
> > >>     warnings produced by allocations made while profiling is disabled
> > >> and freed
> > >>     when it's enabled.
> > >>   +  /proc/sys/vm/mem_profiling_compressed
> > >> +
> > >> +  1: Page extension compression is enabled.
> > >> +
> > >> +  0: Page extension compression is disabled.
> > >> +
> > >> +  This control is read-only and reflects the compression status
> > >> initialized at boot.
> > >> +  Note that, unlike `mem_profiling`, which represents the current
> > >> state of profiling,
> > >> +  `mem_profiling_compressed` represents the state configured at boot
> > >> time.
> >
> >
> > Sorry, I forgot to mention this earlier.
> >
> > I wonder if we could remove this section:
> >
> >
> > >> Turning off
> > >> +  profiling at runtime will implicitly make this sysctl effectively
> > >> dormant. However, if
> > >> +  profiling is toggled off and then toggled on again, it will resume
> > >> with compression
> > >> +  still enabled as long as the value of `mem_profiling_compressed`
> > >> is 1.
> >
> >
> > mem_profiling_compressed only selects the tag storage format (page flags
> > vs page_ext).
> >
> > mem_profiling controls whether allocations are tagged at runtime.
> >
> > The two are independent: toggling mem_profiling on/off has no effect on
> >
> > compression. Only shutdown_mem_profiling() tears it down, but by then
> >
> > the entire allocation profiling subsystem is disabled anyway. There is
> >
> > no resume path.
> >
> >
>
> I added this based on Suren's comment on the previous version asking
> me to explicitly describe the behaviour in the Documentation. The
> original version did not contain it. But personally I do think keeping
> this here makes sense.
>

I checked in with Suren offline and he suggested I reword the
description to make it simpler to understand. I'll shortly send out a
v4 patch with updated documentation. Thanks!

> > >> +
> > >>   Runtime info:
> > >>     /proc/allocinfo
> > >>   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,
> > >> +    },
> > >>   };
> > >>     static void __init sysctl_init(void)
> > >>
> > >> base-commit: 94f9b3980dd446b56acf1dfed649e9b32a9f3813