All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hao Ge <hao.ge@linux.dev>
To: Suren Baghdasaryan <surenb@google.com>,
	Abhishek Bapat <abhishekbapat@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH v3] alloc_tag: expose profiling and compression states
Date: Tue, 4 Aug 2026 09:40:46 +0800	[thread overview]
Message-ID: <7eaf894f-5824-47e8-bcb5-94c0aad52e8b@linux.dev> (raw)
In-Reply-To: <CAJuCfpGA7F80yW1=bSXsZre4=Tx=peqNbkWvKF0up8xJdSvrgA@mail.gmail.com>


On 2026/8/4 08:30, Suren Baghdasaryan wrote:
> On Mon, Aug 3, 2026 at 2:54 PM Abhishek Bapat <abhishekbapat@google.com> 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.mem_profiling_compressed` to output the
> "Resolve this ambiguity by exposing the active compression state by
> adding a new read-only sysctl" sounds too elaborate. This also
> conflicts with the documentation you added which states
> "`mem_profiling_compressed` represents the state configured at boot
> time", so your description of it representing "the active compression
> state" is incorrect.
> How about: "Add a new read-only sysctl representing how compression
> was configured at boot time."?
>
>> 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.
>>
>> Signed-off-by: Abhishek Bapat <abhishekbapat@google.com>
>> ---
>>   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.
> We are not compressing page extensions but rather page allocation
> tags, so "Page extension compression" is misleading. I think "Page
> allocation tag compression is enabled." would be better.


Agree. The commit message describes it the same way ("page extension 
compression"),

so that needs fixing too.


Thanks

Best Regards

Hao


>
>> +
>> +  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. 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.
>> +
>>   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
>> --
>> 2.55.0.508.g3f0d502094-goog
>>


  reply	other threads:[~2026-08-04  4:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-03 21:54 [PATCH v3] alloc_tag: expose profiling and compression states Abhishek Bapat
2026-08-04  0:30 ` Suren Baghdasaryan
2026-08-04  1:40   ` Hao Ge [this message]
2026-08-04  2:15 ` Hao Ge
2026-08-04  3:17   ` Hao Ge
2026-08-04 17:28     ` Abhishek Bapat
2026-08-04 19:59       ` Abhishek Bapat

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7eaf894f-5824-47e8-bcb5-94c0aad52e8b@linux.dev \
    --to=hao.ge@linux.dev \
    --cc=abhishekbapat@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=surenb@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.