linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "David Wang" <00107082@163.com>
To: "Casey Chen" <cachen@purestorage.com>
Cc: akpm@linux-foundation.org, surenb@google.com,
	kent.overstreet@linux.dev, corbet@lwn.net, dennis@kernel.org,
	tj@kernel.org, cl@gentwo.org, vbabka@suse.cz, mhocko@suse.com,
	jackmanb@google.com, hannes@cmpxchg.org, ziy@nvidia.com,
	rientjes@google.com, roman.gushchin@linux.dev,
	harry.yoo@oracle.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
	yzhong@purestorage.com, souravpanda@google.com
Subject: Re: [PATCH v3] alloc_tag: add per-NUMA node stats
Date: Fri, 11 Jul 2025 12:14:35 +0800 (CST)	[thread overview]
Message-ID: <2272d95.4512.197f7b1354f.Coremail.00107082@163.com> (raw)
In-Reply-To: <CALCePG3a6wG+3Nu7-JHha+LMtyRRNF3sXp13sS-=Xv1pvsX09Q@mail.gmail.com>


At 2025-07-11 08:42:05, "Casey Chen" <cachen@purestorage.com> wrote:
>Hi All,
>
>Thanks for reviewing my previous patches. I am replying some comments
>in our previous discussion
>https://lore.kernel.org/all/CAJuCfpHhSUhxer-6MP3503w6520YLfgBTGp7Q9Qm9kgN4TNsfw@mail.gmail.com/T/#u
>
>Most people care about the motivations and usages of this feature.
>Internally, we used to have systems having asymmetric memory to NUMA
>nodes. Node 0 uses a lot of memory but node 1 is pretty empty.
>Requests to allocate memory on node 0 always fail. With this patch, we
>can find the imbalance and optimize the memory usage. Also, David
>Rientjes and Sourav Panda provide their scenarios in which this patch
>would be very useful. It is easy to turn on an off so I think it is
>nice to have, enabling more scenarios in the future.
>
>Andrew / Kent,
>* I agree with Kent on using for_each_possible_cpu rather than
>for_each_online_cpu, considering CPU online/offline.
>* When failing to allocate counters for in-kernel alloc_tag, panic()
>is better than WARN(), eventually the kernel would panic at invalid
>memory access.
>* percpu stats would bloat data structures quite a bit.
>
>David Wang,
>I don't really understand what is 'granularity of calling sites'. If
>NUMA imbalance is found, the calling site could request memory
>allocation from different nodes. Other factors can affect NUMA
>balance, those information can be implemented in a different patch.

I think my concern mostly due to my lack of knowledge and experience of NUMA,
but I still wondering what action to take when " the calling site could request memory
allocation from different nodes", does the calling site needs to detect numa unbalance at runtime
 or it should change to hard coded numa node?

By 'granularity of calling sites', i meant to emphasize that information is local per calling site,
not global.  What if the numa nodes usage are almost balanced globally, but strangely unbalance locally for some calling site.

"what adjustment the calling site would make to solve numa unbalance" is the *big* question to me  

Thanks
David

>
>Thanks,
>Casey
>

  parent reply	other threads:[~2025-07-11  4:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-11  0:23 Casey Chen
2025-07-11  0:42 ` Casey Chen
2025-07-11  0:53   ` Kent Overstreet
2025-07-11  1:07     ` Casey Chen
2025-07-11  3:09       ` Kent Overstreet
2025-07-11 17:41         ` Casey Chen
2025-07-11 18:14           ` Kent Overstreet
2025-07-11  4:14   ` David Wang [this message]
2025-07-24  0:37     ` Casey Chen
2025-07-31 11:55 ` Usama Arif

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=2272d95.4512.197f7b1354f.Coremail.00107082@163.com \
    --to=00107082@163.com \
    --cc=akpm@linux-foundation.org \
    --cc=cachen@purestorage.com \
    --cc=cl@gentwo.org \
    --cc=corbet@lwn.net \
    --cc=dennis@kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=harry.yoo@oracle.com \
    --cc=jackmanb@google.com \
    --cc=kent.overstreet@linux.dev \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=souravpanda@google.com \
    --cc=surenb@google.com \
    --cc=tj@kernel.org \
    --cc=vbabka@suse.cz \
    --cc=yzhong@purestorage.com \
    --cc=ziy@nvidia.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