All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>,
	Wei Yang <richardw.yang@linux.intel.com>,
	linux-mm@kvack.org, akpm@linux-foundation.org,
	anshuman.khandual@arm.com
Subject: Re: [PATCH v2] mm/sparse: set section nid for hot-add memory
Date: Wed, 19 Jun 2019 11:30:17 +0200	[thread overview]
Message-ID: <06d98037-160b-a817-1256-49746da42a0e@redhat.com> (raw)
In-Reply-To: <20190619091658.GL2968@dhcp22.suse.cz>

On 19.06.19 11:16, Michal Hocko wrote:
> On Wed 19-06-19 11:07:30, David Hildenbrand wrote:
>> On 19.06.19 11:04, Michal Hocko wrote:
>>> On Wed 19-06-19 10:51:47, David Hildenbrand wrote:
>>>> On 19.06.19 09:53, Oscar Salvador wrote:
>>>>> 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.
>>>>>
>>>>
>>>> I'd love to see NODE_NOT_IN_PAGE_FLAGS go.
>>>
>>> NODE_NOT_IN_PAGE_FLAGS is an implementation detail on where the
>>> information is stored.
>>
>> Yes and no. Storing it per section clearly doesn't allow storing node
>> information on smaller granularity, like storing in page->flags does.
>>
>> So no, it is not only an implementation detail.
> 
> Let me try to put it differently. NODE_NOT_IN_PAGE_FLAGS is not about
> storing the mapping per section. You can do what ever other data
> structure. NODE_NOT_IN_PAGE_FLAGS is in fact about telling that it is
> not in page->flags.

Okay, I get what you are saying. Storing it differently is problematic,
though, if we want o minimize memory consumption and have a fast lookup.

I was also looking into avoiding to store the section number in
page-flags with CONFIG_SPARSEMEM. Especially, because the
CONFIG_HAVE_ARCH_PFN_VALID hack is really ugly. But it's tricky :(

-- 

Thanks,

David / dhildenb


      reply	other threads:[~2019-06-19  9:30 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
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 [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=06d98037-160b-a817-1256-49746da42a0e@redhat.com \
    --to=david@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=osalvador@suse.de \
    --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.