All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oscar Salvador <osalvador@suse.de>
To: Michal Hocko <mhocko@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>,
	David Hildenbrand <david@redhat.com>,
	Alexey Makhalov <amakhalov@vmware.com>,
	Dennis Zhou <dennis@kernel.org>,
	Eric Dumazet <eric.dumazet@gmail.com>, Tejun Heo <tj@kernel.org>,
	Christoph Lameter <cl@linux.com>, Nico Pache <npache@redhat.com>,
	Wei Yang <richard.weiyang@gmail.com>,
	Rafael Aquini <raquini@redhat.com>,
	Michal Hocko <mhocko@suse.com>
Subject: Re: [PATCH 2/6] mm: handle uninitialized numa nodes gracefully
Date: Fri, 28 Jan 2022 07:27:09 +0100	[thread overview]
Message-ID: <97904ddc17553119fe97801ef5f9193d@suse.de> (raw)
In-Reply-To: <20220127085305.20890-3-mhocko@kernel.org>

On 2022-01-27 09:53, Michal Hocko wrote:
> From: Michal Hocko <mhocko@suse.com>
> 
> We have had several reports [1][2][3] that page allocator blows up when
> an allocation from a possible node is requested. The underlying reason
> is that NODE_DATA for the specific node is not allocated.
> 
> NUMA specific initialization is arch specific and it can vary a lot.
> E.g. x86 tries to initialize all nodes that have some cpu affinity (see
> init_cpu_to_node) but this can be insufficient because the node might 
> be
> cpuless for example.
> 
> One way to address this problem would be to check for !node_online 
> nodes
> when trying to get a zonelist and silently fall back to another node.
> That is unfortunately adding a branch into allocator hot path and it
> doesn't handle any other potential NODE_DATA users.
> 
> This patch takes a different approach (following a lead of [3]) and it
> pre allocates pgdat for all possible nodes in an arch indipendent code
> - free_area_init. All uninitialized nodes are treated as memoryless
> nodes. node_state of the node is not changed because that would lead to
> other side effects - e.g. sysfs representation of such a node and from
> past discussions [4] it is known that some tools might have problems
> digesting that.
> 
> Newly allocated pgdat only gets a minimal initialization and the rest 
> of
> the work is expected to be done by the memory hotplug - 
> hotadd_new_pgdat
> (renamed to hotadd_init_pgdat).
> 
> generic_alloc_nodedata is changed to use the memblock allocator because
> neither page nor slab allocators are available at the stage when all
> pgdats are allocated. Hotplug doesn't allocate pgdat anymore so we can
> use the early boot allocator. The only arch specific implementation is
> ia64 and that is changed to use the early allocator as well.
> 
> Reported-by: Alexey Makhalov <amakhalov@vmware.com>
> Tested-by: Alexey Makhalov <amakhalov@vmware.com>
> Reported-by: Nico Pache <npache@redhat.com>
> Acked-by: Rafael Aquini <raquini@redhat.com>
> Tested-by: Rafael Aquini <raquini@redhat.com>
> Signed-off-by: Michal Hocko <mhocko@suse.com>

With the mentioned fixups:

Reviewed-by: Oscar Salvador <osalvador@suse.de>

-- 
Oscar Salvador
SUSE Labs

  parent reply	other threads:[~2022-01-28  6:27 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-27  8:52 [PATCH 0/6] mm, memory_hotplug: handle unitialized numa node gracefully Michal Hocko
2022-01-27  8:53 ` [PATCH 1/6] mm, memory_hotplug: make arch_alloc_nodedata independent on CONFIG_MEMORY_HOTPLUG Michal Hocko
2022-01-27 12:27   ` David Hildenbrand
2022-01-27 13:36   ` Mike Rapoport
2022-01-28  6:18   ` Oscar Salvador
2022-02-01  2:13   ` Wei Yang
2022-01-27  8:53 ` [PATCH 2/6] mm: handle uninitialized numa nodes gracefully Michal Hocko
2022-01-27 12:41   ` David Hildenbrand
2022-01-27 14:50     ` Michal Hocko
2022-01-27 13:37   ` Mike Rapoport
2022-01-27 14:47     ` Michal Hocko
2022-01-27 15:04       ` Mike Rapoport
2022-02-01  2:41       ` Wei Yang
2022-02-01  9:54         ` Michal Hocko
2022-02-03  0:21           ` Wei Yang
2022-02-03  7:23             ` Mike Rapoport
2022-02-03  8:27               ` David Hildenbrand
2022-02-03  9:08                 ` Mike Rapoport
2022-02-03  9:11                   ` David Hildenbrand
2022-02-03  9:19                     ` Michal Hocko
2022-02-03  9:21                       ` David Hildenbrand
2022-02-03  8:39               ` Michal Hocko
2022-02-04 22:54                 ` Andrew Morton
2022-01-28  6:27   ` Oscar Salvador [this message]
2022-01-31 10:34   ` Michal Hocko
2022-01-27  8:53 ` [PATCH 3/6] mm, memory_hotplug: drop arch_free_nodedata Michal Hocko
2022-01-27 12:42   ` David Hildenbrand
2022-01-27 13:37   ` Mike Rapoport
2022-01-28  6:29   ` Oscar Salvador
2022-02-01  2:41   ` Wei Yang
2022-01-27  8:53 ` [PATCH 4/6] mm, memory_hotplug: reorganize new pgdat initialization Michal Hocko
2022-01-27 12:46   ` David Hildenbrand
2022-01-27 14:44     ` Michal Hocko
2022-02-17 10:40       ` Oscar Salvador
2022-01-27 13:39   ` Mike Rapoport
2022-01-27 14:45     ` Michal Hocko
2022-01-28 10:51   ` Oscar Salvador
2022-02-01  2:42   ` Wei Yang
2022-01-27  8:53 ` [PATCH 5/6] mm: make free_area_init_node aware of memory less nodes Michal Hocko
2022-01-27 12:47   ` David Hildenbrand
2022-01-27 13:34   ` Mike Rapoport
2022-01-28 10:59   ` Oscar Salvador
2022-02-01  2:43   ` Wei Yang
2022-01-27  8:53 ` [PATCH 6/6] memcg: do not tweak node in alloc_mem_cgroup_per_node_info Michal Hocko
2022-01-27 12:50   ` David Hildenbrand
2022-01-28 11:01   ` Oscar Salvador
2022-02-01  2:45   ` Wei Yang
2022-02-01  9:51     ` Michal Hocko

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=97904ddc17553119fe97801ef5f9193d@suse.de \
    --to=osalvador@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=amakhalov@vmware.com \
    --cc=cl@linux.com \
    --cc=david@redhat.com \
    --cc=dennis@kernel.org \
    --cc=eric.dumazet@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=mhocko@suse.com \
    --cc=npache@redhat.com \
    --cc=raquini@redhat.com \
    --cc=richard.weiyang@gmail.com \
    --cc=tj@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.