From: David Vrabel <david.vrabel@citrix.com>
To: Mel Gorman <mgorman@suse.de>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: vmemmap_verify() BUGs during memory hotplug (4.2-rc1 regression)
Date: Mon, 27 Jul 2015 16:32:45 +0100 [thread overview]
Message-ID: <55B64F1D.8090807@citrix.com> (raw)
Mel,
As of commit 8a942fdea560d4ac0e9d9fabcd5201ad20e0c382 (mm: meminit: make
__early_pfn_to_nid SMP-safe and introduce meminit_pfn_in_nid)
vmemmap_verify() will BUG_ON() during memory hotplug because of its use
of early_pfn_to_nid(). Previously, it would have reported bogus (or
failed to report valid) warnings.
I believe this does not affect memory hotplug on most x86 systems
because vmemmap_populate() would normally call
vmemmap_populate_hugepages() which avoids calling vmemmap_verify() in
the common case (no existing mappings covering the new area).
I'm triggering the early_pfn_to_nid() BUG_ON() with the Xen balloon
driver in a PV guest which will always call vmemmap_populate_basepages()
(since Xen PV guests lack superpage support).
Not really sure what the best way to resolve this is. Presumably
vmmemmap_verify() needs to switch to using pfn_to_nid() after the
initial initialization but there doesn't appear to be anything suitable
to distinguish between the early and hotplug cases.
David
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: David Vrabel <david.vrabel@citrix.com>
To: Mel Gorman <mgorman@suse.de>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: vmemmap_verify() BUGs during memory hotplug (4.2-rc1 regression)
Date: Mon, 27 Jul 2015 16:32:45 +0100 [thread overview]
Message-ID: <55B64F1D.8090807@citrix.com> (raw)
Mel,
As of commit 8a942fdea560d4ac0e9d9fabcd5201ad20e0c382 (mm: meminit: make
__early_pfn_to_nid SMP-safe and introduce meminit_pfn_in_nid)
vmemmap_verify() will BUG_ON() during memory hotplug because of its use
of early_pfn_to_nid(). Previously, it would have reported bogus (or
failed to report valid) warnings.
I believe this does not affect memory hotplug on most x86 systems
because vmemmap_populate() would normally call
vmemmap_populate_hugepages() which avoids calling vmemmap_verify() in
the common case (no existing mappings covering the new area).
I'm triggering the early_pfn_to_nid() BUG_ON() with the Xen balloon
driver in a PV guest which will always call vmemmap_populate_basepages()
(since Xen PV guests lack superpage support).
Not really sure what the best way to resolve this is. Presumably
vmmemmap_verify() needs to switch to using pfn_to_nid() after the
initial initialization but there doesn't appear to be anything suitable
to distinguish between the early and hotplug cases.
David
next reply other threads:[~2015-07-27 15:32 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-27 15:32 David Vrabel [this message]
2015-07-27 15:32 ` vmemmap_verify() BUGs during memory hotplug (4.2-rc1 regression) David Vrabel
2015-07-27 15:41 ` Mel Gorman
2015-07-27 15:41 ` Mel Gorman
2015-07-28 17:09 ` David Vrabel
2015-07-28 17:09 ` David Vrabel
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=55B64F1D.8090807@citrix.com \
--to=david.vrabel@citrix.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
/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.