From: Oscar Salvador <osalvador@suse.de>
To: Michal Hocko <mhocko@suse.com>
Cc: Wei Yang <richardw.yang@linux.intel.com>,
linux-mm@kvack.org, akpm@linux-foundation.org, david@redhat.com,
anshuman.khandual@arm.com
Subject: Re: [PATCH v2] mm/sparse: set section nid for hot-add memory
Date: Wed, 19 Jun 2019 09:53:59 +0200 [thread overview]
Message-ID: <20190619075347.GA22552@linux> (raw)
In-Reply-To: <20190619062330.GB5717@dhcp22.suse.cz>
On Wed, Jun 19, 2019 at 08:23:30AM +0200, Michal Hocko wrote:
> On Tue 18-06-19 08:55:37, Wei Yang wrote:
> > In case of NODE_NOT_IN_PAGE_FLAGS is set, we store section's node id in
> > section_to_node_table[]. While for hot-add memory, this is missed.
> > Without this information, page_to_nid() may not give the right node id.
>
> Which would mean that NODE_NOT_IN_PAGE_FLAGS doesn't really work with
> the hotpluged memory, right? Any idea why nobody has noticed this
> so far? Is it because NODE_NOT_IN_PAGE_FLAGS is rare and essentially
> unused with the hotplug? page_to_nid providing an incorrect result
> sounds quite serious to me.
The thing is that for NODE_NOT_IN_PAGE_FLAGS to be enabled we need to run out of
space in page->flags to store zone, nid and section.
Currently, even with the largest values (with pagetable level 5), that is not
possible on x86_64.
It is possible though, that somewhere in the future, when the values get larger
(e.g: we add more zones, NODE_SHIFT grows, or we need more space to store
the section) we finally run out of room for the flags though.
I am not sure about the other arches though, we probably should audit them
and see which ones can fall in there.
--
Oscar Salvador
SUSE L3
next prev parent reply other threads:[~2019-06-19 7:54 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-18 0:55 [PATCH v2] mm/sparse: set section nid for hot-add memory Wei Yang
2019-06-18 7:49 ` Oscar Salvador
2019-06-18 8:32 ` Wei Yang
2019-06-18 8:40 ` David Hildenbrand
2019-06-19 6:10 ` Michal Hocko
2019-06-19 8:54 ` David Hildenbrand
2019-06-19 9:01 ` Michal Hocko
2019-06-19 9:03 ` David Hildenbrand
2019-06-19 9:08 ` Michal Hocko
2019-06-19 9:11 ` David Hildenbrand
2019-06-19 6:23 ` Michal Hocko
2019-06-19 7:53 ` Oscar Salvador [this message]
2019-06-19 8:51 ` David Hildenbrand
2019-06-19 9:04 ` Michal Hocko
2019-06-19 9:07 ` David Hildenbrand
2019-06-19 9:16 ` Michal Hocko
2019-06-19 9:30 ` David Hildenbrand
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=20190619075347.GA22552@linux \
--to=osalvador@suse.de \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=david@redhat.com \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=richardw.yang@linux.intel.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 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.