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

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

[Abhishek Bapat]

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.

Signed-off-by: Abhishek Bapat <abhishekbapat@google.com>
---
 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
-- 
2.55.0.508.g3f0d502094-goog

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

[Hao Ge]

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?


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?


Thanks

Best Regards

Hao


> Signed-off-by: Abhishek Bapat <abhishekbapat@google.com>
> ---
>   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

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

[Abhishek Bapat]

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@linux.dev> 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.

Thanks,
Abhishek.

>
> Thanks
>
> Best Regards
>
> Hao
>
>
> > Signed-off-by: Abhishek Bapat <abhishekbapat@google.com>
> > ---
> >   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

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

[Suren Baghdasaryan]

On Thu, Jul 30, 2026 at 10:57 AM Abhishek Bapat
<abhishekbapat@google.com> 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@linux.dev> 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.




>
> Thanks,
> Abhishek.
>
> >
> > Thanks
> >
> > Best Regards
> >
> > Hao
> >
> >
> > > Signed-off-by: Abhishek Bapat <abhishekbapat@google.com>
> > > ---
> > >   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

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@google.com> wrote:
>
> On Thu, Jul 30, 2026 at 10:57 AM Abhishek Bapat
> <abhishekbapat@google.com> 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@linux.dev> 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@google.com>
> > > > ---
> > > >   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

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

[Suren Baghdasaryan]

On Thu, Jul 30, 2026 at 2:04 PM Abhishek Bapat <abhishekbapat@google.com> wrote:
>
> On Thu, Jul 30, 2026 at 12:49 PM Suren Baghdasaryan <surenb@google.com> wrote:
> >
> > On Thu, Jul 30, 2026 at 10:57 AM Abhishek Bapat
> > <abhishekbapat@google.com> 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@linux.dev> 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?

I think so. Unless someone can think of a better UAPI for it.


>
> Thanks,
> Abhishek.
>
> >
> >
> > >
> > > Thanks,
> > > Abhishek.
> > >
> > > >
> > > > Thanks
> > > >
> > > > Best Regards
> > > >
> > > > Hao
> > > >
> > > >
> > > > > Signed-off-by: Abhishek Bapat <abhishekbapat@google.com>
> > > > > ---
> > > > >   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