[PATCH mm-next] alloc_tag: add total bytes allocation information

[PATCH mm-next] alloc_tag: add total bytes allocation information

[LiZetao]

From bb3537ee638ac80eebcfe9160961e36df8d3ee4c Mon Sep 17 00:00:00 2001
From: Li Zetao <lizetao.kernel@gmail.com>
Date: Tue, 1 Jul 2025 09:30:16 +0000
Subject: [PATCH mm-next] alloc_tag: add total bytes allocation information

Some performance monitoring tools focus on real-time memory
usage anddisplay the total amount of memory applied, which is
convenient for analyzing the memory usage ratio.

Added total information in /proc/allocinfo to feedback the
total amount of memory applied to the user. Example is as
follows:

root:~# cat /proc/allocinfo|tail
       98112      168 lib/radix-tree.c:338 func:__radix_tree_preload
       12848       22 lib/radix-tree.c:276 func:radix_tree_node_alloc
      300760      515 lib/radix-tree.c:253 func:radix_tree_node_alloc
           0        0 lib/xarray.c:1214 func:xas_try_split
           0        0 lib/xarray.c:1059 func:xas_split_alloc
      208488      357 lib/xarray.c:378 func:xas_alloc
           0        0 lib/xarray.c:344 func:__xas_nomem
           0        0 lib/xarray.c:341 func:__xas_nomem
           0        0 lib/xarray.c:309 func:xas_nomem
total: 102208196

Signed-off-by: Li Zetao <lizetao.kernel@gmail.com>
---
 lib/alloc_tag.c | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/lib/alloc_tag.c b/lib/alloc_tag.c
index e9b33848700a..e4e41317a4b7 100644
--- a/lib/alloc_tag.c
+++ b/lib/alloc_tag.c
@@ -43,6 +43,7 @@ int alloc_tag_ref_offs;
 struct allocinfo_private {
  struct codetag_iterator iter;
  bool print_header;
+ long long total;
 };

 static void *allocinfo_start(struct seq_file *m, loff_t *pos)
@@ -53,6 +54,7 @@ static void *allocinfo_start(struct seq_file *m, loff_t *pos)
  priv = (struct allocinfo_private *)m->private;
  codetag_lock_module_list(alloc_tag_cttype, true);
  if (node == 0) {
+ priv->total = 0;
  priv->print_header = true;
  priv->iter = codetag_get_ct_iter(alloc_tag_cttype);
  codetag_next_ct(&priv->iter);
@@ -66,8 +68,16 @@ static void *allocinfo_next(struct seq_file *m,
void *arg, loff_t *pos)
  struct codetag *ct = codetag_next_ct(&priv->iter);

  (*pos)++;
- if (!ct)
+ if (!ct) {
+ char *bufp;
+ size_t n = seq_get_buf(m, &bufp);
+ struct seq_buf buf;
+
+ seq_buf_init(&buf, bufp, n);
+ seq_buf_printf(&buf, "total: %llu\n", priv->total);
+ seq_commit(m, seq_buf_used(&buf));
  return NULL;
+ }

  return priv;
 }
@@ -84,11 +94,13 @@ static void print_allocinfo_header(struct seq_buf *buf)
  seq_buf_printf(buf, "#     <size>  <calls> <tag info>\n");
 }

-static void alloc_tag_to_text(struct seq_buf *out, struct codetag *ct)
+static void alloc_tag_to_text(struct seq_buf *out, struct
allocinfo_private *priv)
 {
+ struct codetag *ct = priv->iter.ct;
  struct alloc_tag *tag = ct_to_alloc_tag(ct);
  struct alloc_tag_counters counter = alloc_tag_read(tag);
  s64 bytes = counter.bytes;
+ priv->total += bytes;

  seq_buf_printf(out, "%12lli %8llu ", bytes, counter.calls);
  codetag_to_text(out, ct);
@@ -108,7 +120,7 @@ static int allocinfo_show(struct seq_file *m, void *arg)
  print_allocinfo_header(&buf);
  priv->print_header = false;
  }
- alloc_tag_to_text(&buf, priv->iter.ct);
+ alloc_tag_to_text(&buf, priv);
  seq_commit(m, seq_buf_used(&buf));
  return 0;
 }
-- 
2.34.1

Re: [PATCH mm-next] alloc_tag: add total bytes allocation information

[Kent Overstreet]

+cc Peter, Ingo, Steven

On Wed, Jul 02, 2025 at 12:38:06AM +0800, LiZetao wrote:
> From bb3537ee638ac80eebcfe9160961e36df8d3ee4c Mon Sep 17 00:00:00 2001
> From: Li Zetao <lizetao.kernel@gmail.com>
> Date: Tue, 1 Jul 2025 09:30:16 +0000
> Subject: [PATCH mm-next] alloc_tag: add total bytes allocation information
> 
> Some performance monitoring tools focus on real-time memory
> usage anddisplay the total amount of memory applied, which is
> convenient for analyzing the memory usage ratio.
> 
> Added total information in /proc/allocinfo to feedback the
> total amount of memory applied to the user. Example is as
> follows:
> 
> root:~# cat /proc/allocinfo|tail
>        98112      168 lib/radix-tree.c:338 func:__radix_tree_preload
>        12848       22 lib/radix-tree.c:276 func:radix_tree_node_alloc
>       300760      515 lib/radix-tree.c:253 func:radix_tree_node_alloc
>            0        0 lib/xarray.c:1214 func:xas_try_split
>            0        0 lib/xarray.c:1059 func:xas_split_alloc
>       208488      357 lib/xarray.c:378 func:xas_alloc
>            0        0 lib/xarray.c:344 func:__xas_nomem
>            0        0 lib/xarray.c:341 func:__xas_nomem
>            0        0 lib/xarray.c:309 func:xas_nomem
> total: 102208196

This makes it harder to process the output (numfmt chokes on lines it
don't understand, which makes the header a real problem).

Given this and the per-numa-node patchset, I am inclined towards adding
an ioctl interface and a userspace tool to do the processing.

Kernel text interfaces are only good when they're simple and unchanging.
We can keep /proc/allocinfo for the basic stuff (it's very nice for
discoverability), and then we could have a tool (maybe in perf) where
you guys can go completely crazy.

Peter, Ingo, want a new perf tool?

Also, memory allocation profiling has been active enough that I'm
wondering if we should either add a mailing list or move it to a less
active one - either perf or tracing, they're both way less busy than mm.

Probably perf, unless Steven is interested. But memory allocation
profiling is the new oddball thing and I dunno what direction we'll go
in more.

Re: [PATCH mm-next] alloc_tag: add total bytes allocation information

[Steven Rostedt]

On Wed, 2 Jul 2025 13:14:20 -0400
Kent Overstreet <kent.overstreet@linux.dev> wrote:

> Also, memory allocation profiling has been active enough that I'm
> wondering if we should either add a mailing list or move it to a less
> active one - either perf or tracing, they're both way less busy than mm.
> 
> Probably perf, unless Steven is interested. But memory allocation
> profiling is the new oddball thing and I dunno what direction we'll go
> in more.

It looks more appropriate for perf, as it is more profiling than tracing.

-- Steve

Re: [PATCH mm-next] alloc_tag: add total bytes allocation information

[Li Zetao]

[-- Attachment #1: Type: text/plain, Size: 2661 bytes --]

Hi,

On 2025/7/3 1:14, Kent Overstreet wrote:
> +cc Peter, Ingo, Steven
>
> On Wed, Jul 02, 2025 at 12:38:06AM +0800, LiZetao wrote:
>>  From bb3537ee638ac80eebcfe9160961e36df8d3ee4c Mon Sep 17 00:00:00 2001
>> From: Li Zetao<lizetao.kernel@gmail.com>
>> Date: Tue, 1 Jul 2025 09:30:16 +0000
>> Subject: [PATCH mm-next] alloc_tag: add total bytes allocation information
>>
>> Some performance monitoring tools focus on real-time memory
>> usage anddisplay the total amount of memory applied, which is
>> convenient for analyzing the memory usage ratio.
>>
>> Added total information in /proc/allocinfo to feedback the
>> total amount of memory applied to the user. Example is as
>> follows:
>>
>> root:~# cat /proc/allocinfo|tail
>>         98112      168 lib/radix-tree.c:338 func:__radix_tree_preload
>>         12848       22 lib/radix-tree.c:276 func:radix_tree_node_alloc
>>        300760      515 lib/radix-tree.c:253 func:radix_tree_node_alloc
>>             0        0 lib/xarray.c:1214 func:xas_try_split
>>             0        0 lib/xarray.c:1059 func:xas_split_alloc
>>        208488      357 lib/xarray.c:378 func:xas_alloc
>>             0        0 lib/xarray.c:344 func:__xas_nomem
>>             0        0 lib/xarray.c:341 func:__xas_nomem
>>             0        0 lib/xarray.c:309 func:xas_nomem
>> total: 102208196
> This makes it harder to process the output (numfmt chokes on lines it
> don't understand, which makes the header a real problem).
>
> Given this and the per-numa-node patchset, I am inclined towards adding
> an ioctl interface and a userspace tool to do the processing.

In my opinion, using ioctl is not very convenient. What do you think if 
a file like

/proc/allocinfo_total can solve this problem?

>
> Kernel text interfaces are only good when they're simple and unchanging.
> We can keep /proc/allocinfo for the basic stuff (it's very nice for
> discoverability), and then we could have a tool (maybe in perf) where
> you guys can go completely crazy.
>
> Peter, Ingo, want a new perf tool?
>
> Also, memory allocation profiling has been active enough that I'm
> wondering if we should either add a mailing list or move it to a less
> active one - either perf or tracing, they're both way less busy than mm.
>
> Probably perf, unless Steven is interested. But memory allocation
> profiling is the new oddball thing and I dunno what direction we'll go
> in more.

Indeed, I often have to check some allocation profiling related mails on the

linux-mm mailing list, which is tedious. Can you consider a separate 
mailing list,

but I am not sure about the development direction of allocation profiling.


---

Li Zetao

[-- Attachment #2: Type: text/html, Size: 3492 bytes --]

Re: [PATCH mm-next] alloc_tag: add total bytes allocation information

[Kent Overstreet]

On Sun, Jul 06, 2025 at 02:01:41PM +0800, Li Zetao wrote:
> Hi,
> 
> On 2025/7/3 1:14, Kent Overstreet wrote:
> > +cc Peter, Ingo, Steven
> > 
> > On Wed, Jul 02, 2025 at 12:38:06AM +0800, LiZetao wrote:
> > >  From bb3537ee638ac80eebcfe9160961e36df8d3ee4c Mon Sep 17 00:00:00 2001
> > > From: Li Zetao<lizetao.kernel@gmail.com>
> > > Date: Tue, 1 Jul 2025 09:30:16 +0000
> > > Subject: [PATCH mm-next] alloc_tag: add total bytes allocation information
> > > 
> > > Some performance monitoring tools focus on real-time memory
> > > usage anddisplay the total amount of memory applied, which is
> > > convenient for analyzing the memory usage ratio.
> > > 
> > > Added total information in /proc/allocinfo to feedback the
> > > total amount of memory applied to the user. Example is as
> > > follows:
> > > 
> > > root:~# cat /proc/allocinfo|tail
> > >         98112      168 lib/radix-tree.c:338 func:__radix_tree_preload
> > >         12848       22 lib/radix-tree.c:276 func:radix_tree_node_alloc
> > >        300760      515 lib/radix-tree.c:253 func:radix_tree_node_alloc
> > >             0        0 lib/xarray.c:1214 func:xas_try_split
> > >             0        0 lib/xarray.c:1059 func:xas_split_alloc
> > >        208488      357 lib/xarray.c:378 func:xas_alloc
> > >             0        0 lib/xarray.c:344 func:__xas_nomem
> > >             0        0 lib/xarray.c:341 func:__xas_nomem
> > >             0        0 lib/xarray.c:309 func:xas_nomem
> > > total: 102208196
> > This makes it harder to process the output (numfmt chokes on lines it
> > don't understand, which makes the header a real problem).
> > 
> > Given this and the per-numa-node patchset, I am inclined towards adding
> > an ioctl interface and a userspace tool to do the processing.
> 
> In my opinion, using ioctl is not very convenient. What do you think if a
> file like
> 
> /proc/allocinfo_total can solve this problem?

We definitely don't want to dump more stuff in /proc, no.

There have been multiple proposals that would dump more stuff in
/proc/allocinfo, and we can't realistically do all that with a text
interface - that needs to stay stable and simple.

A userspace program reading data out via an ioctl will solve all the
things people have been wanting:

- Someone has been reading data out at high frequency for logging pretty
  graphs: we want to avoid string serialization/deserialization

- An ioctl is easier to make extensible (unless we want to go json, but
  I'm not sure the kernel is ready for that...)

- and that gives us a place to add commandline switches and arguments
  for displaying the data different ways (like the top command).

I don't have time to implement it myself, but I can guide someone and do
code review.

Re: [PATCH mm-next] alloc_tag: add total bytes allocation information

[Suren Baghdasaryan]

On Sun, Jul 6, 2025 at 8:21 AM Kent Overstreet
<kent.overstreet@linux.dev> wrote:
>
> On Sun, Jul 06, 2025 at 02:01:41PM +0800, Li Zetao wrote:
> > Hi,
> >
> > On 2025/7/3 1:14, Kent Overstreet wrote:
> > > +cc Peter, Ingo, Steven
> > >
> > > On Wed, Jul 02, 2025 at 12:38:06AM +0800, LiZetao wrote:
> > > >  From bb3537ee638ac80eebcfe9160961e36df8d3ee4c Mon Sep 17 00:00:00 2001
> > > > From: Li Zetao<lizetao.kernel@gmail.com>
> > > > Date: Tue, 1 Jul 2025 09:30:16 +0000
> > > > Subject: [PATCH mm-next] alloc_tag: add total bytes allocation information
> > > >
> > > > Some performance monitoring tools focus on real-time memory
> > > > usage anddisplay the total amount of memory applied, which is
> > > > convenient for analyzing the memory usage ratio.
> > > >
> > > > Added total information in /proc/allocinfo to feedback the
> > > > total amount of memory applied to the user. Example is as
> > > > follows:
> > > >
> > > > root:~# cat /proc/allocinfo|tail
> > > >         98112      168 lib/radix-tree.c:338 func:__radix_tree_preload
> > > >         12848       22 lib/radix-tree.c:276 func:radix_tree_node_alloc
> > > >        300760      515 lib/radix-tree.c:253 func:radix_tree_node_alloc
> > > >             0        0 lib/xarray.c:1214 func:xas_try_split
> > > >             0        0 lib/xarray.c:1059 func:xas_split_alloc
> > > >        208488      357 lib/xarray.c:378 func:xas_alloc
> > > >             0        0 lib/xarray.c:344 func:__xas_nomem
> > > >             0        0 lib/xarray.c:341 func:__xas_nomem
> > > >             0        0 lib/xarray.c:309 func:xas_nomem
> > > > total: 102208196

Sorry for the late reply.
I'm trying to understand why this math has to be done in the kernel.
Why the userspace parser of this file can't simply read the file,
calculate the total allocations size and report it? I don't see the
value of doing that in the kernel as any allocation size can change at
any time even while we are reading this file. So, if you are concerned
about correctness of the reported total, it won't be any more correct
even if you do this inside the kernel AFAICT.

> > > This makes it harder to process the output (numfmt chokes on lines it
> > > don't understand, which makes the header a real problem).
> > >
> > > Given this and the per-numa-node patchset, I am inclined towards adding
> > > an ioctl interface and a userspace tool to do the processing.
> >
> > In my opinion, using ioctl is not very convenient. What do you think if a
> > file like
> >
> > /proc/allocinfo_total can solve this problem?
>
> We definitely don't want to dump more stuff in /proc, no.
>
> There have been multiple proposals that would dump more stuff in
> /proc/allocinfo, and we can't realistically do all that with a text
> interface - that needs to stay stable and simple.
>
> A userspace program reading data out via an ioctl will solve all the
> things people have been wanting:
>
> - Someone has been reading data out at high frequency for logging pretty
>   graphs: we want to avoid string serialization/deserialization
>
> - An ioctl is easier to make extensible (unless we want to go json, but
>   I'm not sure the kernel is ready for that...)
>
> - and that gives us a place to add commandline switches and arguments
>   for displaying the data different ways (like the top command).
>
> I don't have time to implement it myself, but I can guide someone and do
> code review.

Re: [PATCH mm-next] alloc_tag: add total bytes allocation information

[Kent Overstreet]

On Mon, Jul 07, 2025 at 07:05:18PM -0700, Suren Baghdasaryan wrote:
> On Sun, Jul 6, 2025 at 8:21 AM Kent Overstreet
> <kent.overstreet@linux.dev> wrote:
> >
> > On Sun, Jul 06, 2025 at 02:01:41PM +0800, Li Zetao wrote:
> > > Hi,
> > >
> > > On 2025/7/3 1:14, Kent Overstreet wrote:
> > > > +cc Peter, Ingo, Steven
> > > >
> > > > On Wed, Jul 02, 2025 at 12:38:06AM +0800, LiZetao wrote:
> > > > >  From bb3537ee638ac80eebcfe9160961e36df8d3ee4c Mon Sep 17 00:00:00 2001
> > > > > From: Li Zetao<lizetao.kernel@gmail.com>
> > > > > Date: Tue, 1 Jul 2025 09:30:16 +0000
> > > > > Subject: [PATCH mm-next] alloc_tag: add total bytes allocation information
> > > > >
> > > > > Some performance monitoring tools focus on real-time memory
> > > > > usage anddisplay the total amount of memory applied, which is
> > > > > convenient for analyzing the memory usage ratio.
> > > > >
> > > > > Added total information in /proc/allocinfo to feedback the
> > > > > total amount of memory applied to the user. Example is as
> > > > > follows:
> > > > >
> > > > > root:~# cat /proc/allocinfo|tail
> > > > >         98112      168 lib/radix-tree.c:338 func:__radix_tree_preload
> > > > >         12848       22 lib/radix-tree.c:276 func:radix_tree_node_alloc
> > > > >        300760      515 lib/radix-tree.c:253 func:radix_tree_node_alloc
> > > > >             0        0 lib/xarray.c:1214 func:xas_try_split
> > > > >             0        0 lib/xarray.c:1059 func:xas_split_alloc
> > > > >        208488      357 lib/xarray.c:378 func:xas_alloc
> > > > >             0        0 lib/xarray.c:344 func:__xas_nomem
> > > > >             0        0 lib/xarray.c:341 func:__xas_nomem
> > > > >             0        0 lib/xarray.c:309 func:xas_nomem
> > > > > total: 102208196
> 
> Sorry for the late reply.
> I'm trying to understand why this math has to be done in the kernel.
> Why the userspace parser of this file can't simply read the file,
> calculate the total allocations size and report it? I don't see the
> value of doing that in the kernel as any allocation size can change at
> any time even while we are reading this file. So, if you are concerned
> about correctness of the reported total, it won't be any more correct
> even if you do this inside the kernel AFAICT.

exactly - hoping to nudge someone to write the userspace frontend :)

Re: [PATCH mm-next] alloc_tag: add total bytes allocation information

[Suren Baghdasaryan]

On Mon, Jul 7, 2025 at 7:16 PM Kent Overstreet
<kent.overstreet@linux.dev> wrote:
>
> On Mon, Jul 07, 2025 at 07:05:18PM -0700, Suren Baghdasaryan wrote:
> > On Sun, Jul 6, 2025 at 8:21 AM Kent Overstreet
> > <kent.overstreet@linux.dev> wrote:
> > >
> > > On Sun, Jul 06, 2025 at 02:01:41PM +0800, Li Zetao wrote:
> > > > Hi,
> > > >
> > > > On 2025/7/3 1:14, Kent Overstreet wrote:
> > > > > +cc Peter, Ingo, Steven
> > > > >
> > > > > On Wed, Jul 02, 2025 at 12:38:06AM +0800, LiZetao wrote:
> > > > > >  From bb3537ee638ac80eebcfe9160961e36df8d3ee4c Mon Sep 17 00:00:00 2001
> > > > > > From: Li Zetao<lizetao.kernel@gmail.com>
> > > > > > Date: Tue, 1 Jul 2025 09:30:16 +0000
> > > > > > Subject: [PATCH mm-next] alloc_tag: add total bytes allocation information
> > > > > >
> > > > > > Some performance monitoring tools focus on real-time memory
> > > > > > usage anddisplay the total amount of memory applied, which is
> > > > > > convenient for analyzing the memory usage ratio.
> > > > > >
> > > > > > Added total information in /proc/allocinfo to feedback the
> > > > > > total amount of memory applied to the user. Example is as
> > > > > > follows:
> > > > > >
> > > > > > root:~# cat /proc/allocinfo|tail
> > > > > >         98112      168 lib/radix-tree.c:338 func:__radix_tree_preload
> > > > > >         12848       22 lib/radix-tree.c:276 func:radix_tree_node_alloc
> > > > > >        300760      515 lib/radix-tree.c:253 func:radix_tree_node_alloc
> > > > > >             0        0 lib/xarray.c:1214 func:xas_try_split
> > > > > >             0        0 lib/xarray.c:1059 func:xas_split_alloc
> > > > > >        208488      357 lib/xarray.c:378 func:xas_alloc
> > > > > >             0        0 lib/xarray.c:344 func:__xas_nomem
> > > > > >             0        0 lib/xarray.c:341 func:__xas_nomem
> > > > > >             0        0 lib/xarray.c:309 func:xas_nomem
> > > > > > total: 102208196
> >
> > Sorry for the late reply.
> > I'm trying to understand why this math has to be done in the kernel.
> > Why the userspace parser of this file can't simply read the file,
> > calculate the total allocations size and report it? I don't see the
> > value of doing that in the kernel as any allocation size can change at
> > any time even while we are reading this file. So, if you are concerned
> > about correctness of the reported total, it won't be any more correct
> > even if you do this inside the kernel AFAICT.
>
> exactly - hoping to nudge someone to write the userspace frontend :)

Why not just use what we already have?

awk '{sum += $1} END {print sum}' /proc/allocinfo

Re: [PATCH mm-next] alloc_tag: add total bytes allocation information

[Kent Overstreet]

On Tue, Jul 08, 2025 at 07:38:40AM -0700, Suren Baghdasaryan wrote:
> Why not just use what we already have?
> 
> awk '{sum += $1} END {print sum}' /proc/allocinfo

For this sure, but there've been several feature requests - the per numa
node stats is the big one that I think would justify a more extensible
ioctl interface. We don't want to change the existing /proc/allocinfo
for that.

The big thing on my mind is starting to come up with an API for getting
this into other userspace tooling; if we could eventually figure how to
to teach perf to do the address -> owner lookup for cache misses that
would be huge.

Re: [PATCH mm-next] alloc_tag: add total bytes allocation information

[Suren Baghdasaryan]

On Tue, Jul 8, 2025 at 8:13 AM Kent Overstreet
<kent.overstreet@linux.dev> wrote:
>
> On Tue, Jul 08, 2025 at 07:38:40AM -0700, Suren Baghdasaryan wrote:
> > Why not just use what we already have?
> >
> > awk '{sum += $1} END {print sum}' /proc/allocinfo
>
> For this sure, but there've been several feature requests - the per numa
> node stats is the big one that I think would justify a more extensible
> ioctl interface. We don't want to change the existing /proc/allocinfo
> for that.

I see. About the NUMA awareness patch proposed at
https://lore.kernel.org/all/20250610233053.973796-1-cachen@purestorage.com/,
I'm checking with other teams at Google whether this would be useful.
For Android which always uses a single NUMA node that's obviously not
very interesting but for others it might be. Will follow up on that
thread once I have some more info.

>
> The big thing on my mind is starting to come up with an API for getting
> this into other userspace tooling; if we could eventually figure how to
> to teach perf to do the address -> owner lookup for cache misses that
> would be huge.

Re: [PATCH mm-next] alloc_tag: add total bytes allocation information

[Kent Overstreet]

On Tue, Jul 08, 2025 at 08:22:09AM -0700, Suren Baghdasaryan wrote:
> On Tue, Jul 8, 2025 at 8:13 AM Kent Overstreet
> <kent.overstreet@linux.dev> wrote:
> >
> > On Tue, Jul 08, 2025 at 07:38:40AM -0700, Suren Baghdasaryan wrote:
> > > Why not just use what we already have?
> > >
> > > awk '{sum += $1} END {print sum}' /proc/allocinfo
> >
> > For this sure, but there've been several feature requests - the per numa
> > node stats is the big one that I think would justify a more extensible
> > ioctl interface. We don't want to change the existing /proc/allocinfo
> > for that.
> 
> I see. About the NUMA awareness patch proposed at
> https://lore.kernel.org/all/20250610233053.973796-1-cachen@purestorage.com/,
> I'm checking with other teams at Google whether this would be useful.
> For Android which always uses a single NUMA node that's obviously not
> very interesting but for others it might be. Will follow up on that
> thread once I have some more info.

Know anyone with expertise on the perf side?

I've been wondering (and haven't had time to check) if the CPU events
that perf consumes can report on the cacheline of the data miss, not
just the instruction we stalled on.