On Thu, Oct 24, 2024 at 10:24:56AM +0200, Michal Hocko wrote: > On Wed 23-10-24 21:54:37, Dongjoo Seo wrote: > > On Thu, Oct 24, 2024 at 12:23:56AM +0200, Michal Hocko wrote: > > > On Wed 23-10-24 15:15:20, Dongjoo Seo wrote: > > > > Hi Andrew, Michal, > > > > > > > > Thanks for the feedback. > > > > > > > > The issue is that CPU-less nodes can lead to incorrect NUMA stats. > > > > For example, NUMA_HIT may incorrectly increase for CPU-less nodes > > > > because the current logic doesn't account for whether a node has CPUs. > > > > > > Define incorrect > > > > > > Current semantic doesn't really care about cpu less NUMA nodes because > > > current means whatever is required AFIU. This is certainly a long term > > > > I agree that, in the long term, special logging for preferred_zone > > and a separate counter might be necessary for CPU-less nodes. > > > > > semantic. Why does this need to change and why it makes sense to > > > pre-existing users? > > > > This patch doesn't change existing logic; the additional logic only > > applies when a CPU-less node is present, so there shouldn't be > > concerns for pre-existing users. Currently, the NUMA stats for > > configurations with CPU-less nodes are incorrect, as allocations > > are not properly accounted for. > > > > I believe this approach improves logging accuracy with minimal impact > > on the memory allocation path, but I'm open to alternative solutions. > > This isn't the only way to address the issue—any suggestions? > > I still do not understand the actual problem. CPU-less nodes are nothing > really special. They just never have local allocations for obvious > reasons. NUMA_HIT which your patch is special casing has a very well > defined meaning and that is that the memory allocated matches the > preferred node. That doesn't have any notion of CPU at all. Say somebody > explicitly requests to allocate from a CPU less node. Why should you > consider thiat as NUMA_OTHER just because that node has no CPUs? That > just seems completely wrong. Thank you for your feedback. After reviewing ur reply and [1], I realize my misunderstanding of numa_* stats. I mistakenly assumed node referred to CPU locality. The current logic is indeed memory-centric and operates correctly as it is. I appreciate the clarification, and I now understand that no changes are needed to special case CPU-less nodes in this context. Thanks again for pointing this out. [1] https://docs.kernel.org/admin-guide/numastat.html > -- > Michal Hocko > SUSE Labs