linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: david@redhat.com, kkabe@vega.pgw.jp, Oscar Salvador <osalvador@suse.de>
Cc: bugzilla-daemon@bugzilla.kernel.org, akpm@linux-foundation.org,
	richardw.yang@linux.intel.com, mhocko@kernel.org,
	n-horiguchi@ah.jp.nec.com, linux-mm@kvack.org
Subject: Re: [Bug 206401] kernel panic on Hyper-V after 5 minutes due to memory hot-add
Date: Mon, 17 Feb 2020 18:13:18 +0800	[thread overview]
Message-ID: <20200217101318.GL26758@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20200217093447.GA1139@linux>

On 02/17/20 at 10:34am, Oscar Salvador wrote:
> On Mon, Feb 17, 2020 at 02:46:27PM +0900, kkabe@vega.pgw.jp wrote:
> > ===========================================
> > struct page * __meminit populate_section_memmap(unsigned long pfn,
> >                 unsigned long nr_pages, int nid, struct vmem_altmap *altmap)
> > {
> >         struct page *page, *ret;
> >         unsigned long memmap_size = sizeof(struct page) * PAGES_PER_SECTION;
> > 
> >         page = alloc_pages(GFP_KERNEL|__GFP_NOWARN, get_order(memmap_size));
> >         if (page) {
> >                 goto got_map_page;
> >         }
> > pr_info("%s: alloc_pages() returned 0x%p (should be 0), reverting to vmalloc(memmap_size=%lu)\n", __func__, page, memmap_size);
> > BUG_ON(page != 0);
> > 
> >         ret = vmalloc(memmap_size);
> > pr_info("%s: vmalloc(%lu) returned 0x%p\n", __func__, memmap_size, ret);
> >         if (ret) {
> >                 goto got_map_ptr;
> >         }
> > 
> >         return NULL;
> > got_map_page:
> >         ret = (struct page *)pfn_to_kaddr(page_to_pfn(page));
> > pr_info("%s: allocated struct page *page=0x%p\n", __func__, page);
> > got_map_ptr:
> > 
> > pr_info("%s: returning struct page * =0x%p\n", __func__, ret);
> >         return ret;
> > }
> 
> Could you please replace %p with %px. Wih the first, pointers are hashed so it is trickier
> to get an overview of the meaning.
> 
> David could be right about ZONE_NORMAL vs ZONE_HIGHMEM.
> IIUC, default_kernel_zone_for_pfn and default_zone_for_pfn seem to only deal with
> (ZONE_DMA,ZONE_NORMAL] or ZONE_MOVABLE.

Ah, I think you both have spotted the problem.
 
In i386, if w/o momory hot add, normal memory will only include those
below 896M and they are added into normal zone. The left are added into
highmem zone.
 
How this influence the page allocation?
 
Very huge. As we know, in i386, normal memory can be accessed with
virt_to_phys, namely PAGE_OFFSET + phys. But highmem has to be accessed
with kmap. However, the later hot added memory are all put into normal
memmory, accessing into them will stump into vmalloc area, I would say.
 
So, i386 doesn't support memory hot add well.  Not sure if below change
can make it work normally.
 
We can just adjus the hot adding code as we have done for boot memmory.
Iterate zone from highmem if allowed when hot add memory.
 
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 475d0d68a32c..1380392d9ef5 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -716,7 +716,10 @@ static struct zone *default_kernel_zone_for_pfn(int nid, unsigned long start_pfn
 	struct pglist_data *pgdat = NODE_DATA(nid);
 	int zid;
 
-	for (zid = 0; zid <= ZONE_NORMAL; zid++) {
+	for (zid = 0; zid < MAX_NR_ZONES; zid++) {
+		if (zid == ZONE_MOVABLE)
+			continue;
+
 		struct zone *zone = &pgdat->node_zones[zid];
 
 		if (zone_intersects(zone, start_pfn, nr_pages))




  reply	other threads:[~2020-02-17 10:13 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-206401-27@https.bugzilla.kernel.org/>
     [not found] ` <bug-206401-27-zYD8WfDKqD@https.bugzilla.kernel.org/>
2020-02-10  5:32   ` [Bug 206401] kernel panic on Hyper-V after 5 minutes due to memory hot-add Andrew Morton
2020-02-10  5:40     ` Baoquan He
2020-02-10  5:56       ` Andrew Morton
2020-02-10  6:09         ` Baoquan He
2020-02-10  6:15           ` Baoquan He
2020-02-10 23:07             ` Wei Yang
2020-02-12  0:41               ` Andrew Morton
2020-02-12  7:31                 ` Baoquan He
2020-02-12  8:21                   ` David Hildenbrand
2020-02-13  4:22                   ` [Bug 206401] kernel panic on Hyper-V after 5 minutes due tomemory hot-add kabe
2020-02-13  8:19                     ` Baoquan He
2020-02-14 14:26                       ` [Bug 206401] kernel panic on Hyper-V after 5 minutes duetomemory hot-add kkabe
2020-02-14 14:48                         ` Baoquan He
2020-02-14 15:01                           ` Baoquan He
2020-02-17  4:48                         ` Baoquan He
2020-02-17  5:31                           ` [Bug 206401] kernel panic on Hyper-V after 5 minutes duetomemoryhot-add kkabe
2020-02-17  8:00                             ` David Hildenbrand
2020-02-17 10:33                         ` [Bug 206401] kernel panic on Hyper-V after 5 minutes duetomemory hot-add Michal Hocko
2020-02-17 11:21                           ` [Bug 206401] kernel panic on Hyper-V after 5 minutes due to memory hot-add kkabe
2020-02-17  5:46                   ` kkabe
2020-02-17  7:44                     ` Baoquan He
2020-02-17  9:34                     ` Oscar Salvador
2020-02-17 10:13                       ` Baoquan He [this message]
2020-02-17 10:17                         ` Baoquan He
2020-02-17 10:24                         ` David Hildenbrand
2020-02-17 10:33                           ` Baoquan He
2020-02-17 10:38                             ` David Hildenbrand
2020-02-17 11:20                               ` Baoquan He
2020-02-17 12:47                                 ` Michal Hocko
2020-02-18  6:24                                 ` kkabe
2020-02-18  8:47                                   ` Michal Hocko
2020-02-18  9:19                                     ` kkabe
2020-02-18  9:26                                       ` David Hildenbrand
2020-02-18 10:05                                       ` [RFC PATCH] memory_hotplug: disable the functionality for 32b (was: Re: [Bug 206401] kernel panic on Hyper-V after 5 minutes due to) " Michal Hocko
2020-02-18 10:11                                         ` David Hildenbrand
2020-02-19  3:23                                         ` Baoquan He
2020-02-19 21:46                                         ` Andrew Morton
2020-02-19 23:07                                           ` [RFC PATCH] memory_hotplug: disable the functionality for 32b Robin Murphy
2020-02-19  3:39                                   ` [Bug 206401] kernel panic on Hyper-V after 5 minutes due to memory hot-add Baoquan He

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=20200217101318.GL26758@MiWiFi-R3L-srv \
    --to=bhe@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=bugzilla-daemon@bugzilla.kernel.org \
    --cc=david@redhat.com \
    --cc=kkabe@vega.pgw.jp \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=n-horiguchi@ah.jp.nec.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).