linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Kent Overstreet <kent.overstreet@linux.dev>
To: Suren Baghdasaryan <surenb@google.com>
Cc: Li Zetao <lizetao.kernel@gmail.com>,
	 Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	 Steven Rostedt <rostedt@goodmis.org>,
	akpm@linux-foundation.org, linux-mm@kvack.org
Subject: Re: [PATCH mm-next] alloc_tag: add total bytes allocation information
Date: Tue, 8 Jul 2025 13:23:54 -0400	[thread overview]
Message-ID: <oy7saulyezk4fkt3dbnfbnedtjtri6gu32nqs5c3kriynu55p7@npuewy4tbupg> (raw)
In-Reply-To: <CAJuCfpEvtDShFzawofmBBWkF5RzoeuESW2CEM1nhnpasTRJTCA@mail.gmail.com>

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.


      reply	other threads:[~2025-07-08 17:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-01 16:38 LiZetao
2025-07-02 17:14 ` Kent Overstreet
2025-07-02 20:19   ` Steven Rostedt
2025-07-06  6:01   ` Li Zetao
2025-07-06 15:21     ` Kent Overstreet
2025-07-08  2:05       ` Suren Baghdasaryan
2025-07-08  2:16         ` Kent Overstreet
2025-07-08 14:38           ` Suren Baghdasaryan
2025-07-08 15:13             ` Kent Overstreet
2025-07-08 15:22               ` Suren Baghdasaryan
2025-07-08 17:23                 ` Kent Overstreet [this message]

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=oy7saulyezk4fkt3dbnfbnedtjtri6gu32nqs5c3kriynu55p7@npuewy4tbupg \
    --to=kent.overstreet@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=linux-mm@kvack.org \
    --cc=lizetao.kernel@gmail.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox