From: Michal Hocko <mhocko@kernel.org> To: Reza Arbab <arbab@linux.vnet.ibm.com> Cc: Mel Gorman <mgorman@suse.de>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Vlastimil Babka <vbabka@suse.cz>, Andrea Arcangeli <aarcange@redhat.com>, Yasuaki Ishimatsu <yasu.isimatu@gmail.com>, Tang Chen <tangchen@cn.fujitsu.com>, qiuxishi@huawei.com, Kani Toshimitsu <toshi.kani@hpe.com>, slaoub@gmail.com, Joonsoo Kim <js1304@gmail.com>, Andi Kleen <ak@linux.intel.com>, Zhang Zhen <zhenzhang.zhang@huawei.com>, David Rientjes <rientjes@google.com>, Daniel Kiper <daniel.kiper@oracle.com>, Igor Mammedov <imammedo@redhat.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, LKML <linux-kernel@vger.kernel.org>, Chris Metcalf <cmetcalf@mellanox.com>, Dan Williams <dan.j.williams@gmail.com>, Heiko Carstens <heiko.carstens@de.ibm.com>, Lai Jiangshan <laijs@cn.fujitsu.com>, Martin Schwidefsky <schwidefsky@de.ibm.com> Subject: Re: [PATCH 0/6] mm: make movable onlining suck less Date: Wed, 5 Apr 2017 15:52:49 +0200 [thread overview] Message-ID: <20170405135248.GQ6035@dhcp22.suse.cz> (raw) In-Reply-To: <20170404214339.6o4c4uhwudyhzbbo@arbab-laptop> On Tue 04-04-17 16:43:39, Reza Arbab wrote: > On Tue, Apr 04, 2017 at 09:41:22PM +0200, Michal Hocko wrote: > >On Tue 04-04-17 13:30:13, Reza Arbab wrote: > >>I think I found another edge case. You > >>get an oops when removing all of a node's memory: > >> > >>__nr_to_section > >>__pfn_to_section > >>find_biggest_section_pfn > >>shrink_pgdat_span > >>__remove_zone > >>__remove_section > >>__remove_pages > >>arch_remove_memory > >>remove_memory > > > >Is this something new or an old issue? I believe the state after the > >online should be the same as before. So if you onlined the full node > >then there shouldn't be any difference. Let me have a look... > > It's new. Without this patchset, I can repeatedly > add_memory()->online_movable->offline->remove_memory() all of a node's > memory. OK, I know what is going on here. shrink_pgdat_span: start_pfn=0x1ff00, end_pfn=0x20000, pgdat_start_pfn=0x0, pgdat_end_pfn=0x20000 [...] find_biggest_section_pfn loop: pfn=0xff, sec_nr = 0x0 so the node starts at pfn 0 while we are trying to remove range starting from pfn=255 (1MB). Rather than going with find_smallest_section_pfn we go with the other branch and that underflows as already mentioned. I seriously doubt that the node really starts at pfn 0. I am not sure which arch you are testing on but I believe we reserve the lowest address pfn range on all aches. The previous code presumably handled that properly because the original node/zone has started at the lowest possible address and the zone shifting then preserves that. My code doesn't do that though. So I guess I have to sanitize. Does this help? Please drop the "mm, memory_hotplug: get rid of zone/node shrinking" patch. --- diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index acf2b5eb5ecb..2c5613d19eb6 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -750,6 +750,15 @@ int __ref online_pages(unsigned long pfn, unsigned long nr_pages, int online_typ int ret; struct memory_notify arg; + do { + if (pfn_valid(pfn)) + break; + pfn++; + } while (--nr_pages > 0); + + if (!nr_pages) + return -EINVAL; + nid = pfn_to_nid(pfn); if (!allow_online_pfn_range(nid, pfn, nr_pages, online_type)) return -EINVAL; -- Michal Hocko SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org> To: Reza Arbab <arbab@linux.vnet.ibm.com> Cc: Mel Gorman <mgorman@suse.de>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Vlastimil Babka <vbabka@suse.cz>, Andrea Arcangeli <aarcange@redhat.com>, Yasuaki Ishimatsu <yasu.isimatu@gmail.com>, Tang Chen <tangchen@cn.fujitsu.com>, qiuxishi@huawei.com, Kani Toshimitsu <toshi.kani@hpe.com>, slaoub@gmail.com, Joonsoo Kim <js1304@gmail.com>, Andi Kleen <ak@linux.intel.com>, Zhang Zhen <zhenzhang.zhang@huawei.com>, David Rientjes <rientjes@google.com>, Daniel Kiper <daniel.kiper@oracle.com>, Igor Mammedov <imammedo@redhat.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, LKML <linux-kernel@vger.kernel.org>, Chris Metcalf <cmetcalf@mellanox.com>, Dan Williams <dan.j.williams@gmail.com>, Heiko Carstens <heiko.carstens@de.ibm.com>, Lai Jiangshan <laijs@cn.fujitsu.com>, Martin Schwidefsky <schwidefsky@de.ibm.com> Subject: Re: [PATCH 0/6] mm: make movable onlining suck less Date: Wed, 5 Apr 2017 15:52:49 +0200 [thread overview] Message-ID: <20170405135248.GQ6035@dhcp22.suse.cz> (raw) In-Reply-To: <20170404214339.6o4c4uhwudyhzbbo@arbab-laptop> On Tue 04-04-17 16:43:39, Reza Arbab wrote: > On Tue, Apr 04, 2017 at 09:41:22PM +0200, Michal Hocko wrote: > >On Tue 04-04-17 13:30:13, Reza Arbab wrote: > >>I think I found another edge case. You > >>get an oops when removing all of a node's memory: > >> > >>__nr_to_section > >>__pfn_to_section > >>find_biggest_section_pfn > >>shrink_pgdat_span > >>__remove_zone > >>__remove_section > >>__remove_pages > >>arch_remove_memory > >>remove_memory > > > >Is this something new or an old issue? I believe the state after the > >online should be the same as before. So if you onlined the full node > >then there shouldn't be any difference. Let me have a look... > > It's new. Without this patchset, I can repeatedly > add_memory()->online_movable->offline->remove_memory() all of a node's > memory. OK, I know what is going on here. shrink_pgdat_span: start_pfn=0x1ff00, end_pfn=0x20000, pgdat_start_pfn=0x0, pgdat_end_pfn=0x20000 [...] find_biggest_section_pfn loop: pfn=0xff, sec_nr = 0x0 so the node starts at pfn 0 while we are trying to remove range starting from pfn=255 (1MB). Rather than going with find_smallest_section_pfn we go with the other branch and that underflows as already mentioned. I seriously doubt that the node really starts at pfn 0. I am not sure which arch you are testing on but I believe we reserve the lowest address pfn range on all aches. The previous code presumably handled that properly because the original node/zone has started at the lowest possible address and the zone shifting then preserves that. My code doesn't do that though. So I guess I have to sanitize. Does this help? Please drop the "mm, memory_hotplug: get rid of zone/node shrinking" patch. --- diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index acf2b5eb5ecb..2c5613d19eb6 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -750,6 +750,15 @@ int __ref online_pages(unsigned long pfn, unsigned long nr_pages, int online_typ int ret; struct memory_notify arg; + do { + if (pfn_valid(pfn)) + break; + pfn++; + } while (--nr_pages > 0); + + if (!nr_pages) + return -EINVAL; + nid = pfn_to_nid(pfn); if (!allow_online_pfn_range(nid, pfn, nr_pages, online_type)) return -EINVAL; -- Michal Hocko SUSE Labs -- 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>
next prev parent reply other threads:[~2017-04-05 13:54 UTC|newest] Thread overview: 140+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-03-30 11:54 [PATCH 0/6] mm: make movable onlining suck less Michal Hocko 2017-03-30 11:54 ` Michal Hocko 2017-03-30 11:54 ` [PATCH 1/6] mm: get rid of zone_is_initialized Michal Hocko 2017-03-30 11:54 ` Michal Hocko 2017-03-31 3:39 ` Hillf Danton 2017-03-31 3:39 ` Hillf Danton 2017-03-31 6:43 ` Michal Hocko 2017-03-31 6:43 ` Michal Hocko 2017-03-31 6:48 ` Michal Hocko 2017-03-31 6:48 ` Michal Hocko 2017-03-31 7:39 ` [PATCH v1 " Michal Hocko 2017-03-31 7:39 ` Michal Hocko 2017-04-05 8:14 ` Michal Hocko 2017-04-05 8:14 ` Michal Hocko 2017-04-05 9:06 ` Igor Mammedov 2017-04-05 9:06 ` Igor Mammedov 2017-04-05 9:23 ` Michal Hocko 2017-04-05 9:23 ` Michal Hocko 2017-03-30 11:54 ` [PATCH 2/6] mm, tile: drop arch_{add,remove}_memory Michal Hocko 2017-03-30 11:54 ` Michal Hocko 2017-03-30 15:41 ` Chris Metcalf 2017-03-30 15:41 ` Chris Metcalf 2017-03-30 11:54 ` [PATCH 3/6] mm: remove return value from init_currently_empty_zone Michal Hocko 2017-03-30 11:54 ` Michal Hocko 2017-03-31 3:49 ` Hillf Danton 2017-03-31 3:49 ` Hillf Danton 2017-03-31 6:49 ` Michal Hocko 2017-03-31 6:49 ` Michal Hocko 2017-03-31 7:06 ` Hillf Danton 2017-03-31 7:06 ` Hillf Danton 2017-03-31 7:18 ` Michal Hocko 2017-03-31 7:18 ` Michal Hocko 2017-03-31 7:43 ` Michal Hocko 2017-03-31 7:43 ` Michal Hocko 2017-04-03 21:22 ` Reza Arbab 2017-04-03 21:22 ` Reza Arbab 2017-04-04 7:30 ` Michal Hocko 2017-04-04 7:30 ` Michal Hocko 2017-03-30 11:54 ` [PATCH 4/6] mm, memory_hotplug: use node instead of zone in can_online_high_movable Michal Hocko 2017-03-30 11:54 ` Michal Hocko 2017-03-30 11:54 ` [PATCH 5/6] mm, memory_hotplug: do not associate hotadded memory to zones until online Michal Hocko 2017-03-30 11:54 ` Michal Hocko 2017-03-31 6:18 ` Hillf Danton 2017-03-31 6:18 ` Hillf Danton 2017-03-31 6:50 ` Michal Hocko 2017-03-31 6:50 ` Michal Hocko 2017-04-04 12:21 ` Tobias Regnery 2017-04-04 12:21 ` Tobias Regnery 2017-04-04 12:45 ` Michal Hocko 2017-04-04 12:45 ` Michal Hocko 2017-04-06 8:14 ` Michal Hocko 2017-04-06 8:14 ` Michal Hocko 2017-04-06 12:46 ` Michal Hocko 2017-04-06 12:46 ` Michal Hocko 2017-03-30 11:54 ` [PATCH 6/6] mm, memory_hotplug: remove unused cruft after memory hotplug rework Michal Hocko 2017-03-30 11:54 ` Michal Hocko 2017-03-31 7:46 ` Michal Hocko 2017-03-31 7:46 ` Michal Hocko 2017-03-31 19:19 ` [PATCH 0/6] mm: make movable onlining suck less Heiko Carstens 2017-03-31 19:19 ` Heiko Carstens 2017-04-03 7:34 ` Michal Hocko 2017-04-03 7:34 ` Michal Hocko 2017-04-03 11:55 ` Michal Hocko 2017-04-03 11:55 ` Michal Hocko 2017-04-03 12:20 ` Igor Mammedov 2017-04-03 12:20 ` Igor Mammedov 2017-04-03 19:58 ` Reza Arbab 2017-04-03 19:58 ` Reza Arbab 2017-04-03 20:23 ` Michal Hocko 2017-04-03 20:23 ` Michal Hocko 2017-04-03 20:42 ` Reza Arbab 2017-04-03 20:42 ` Reza Arbab 2017-04-04 7:23 ` Michal Hocko 2017-04-04 7:23 ` Michal Hocko 2017-04-04 7:34 ` Michal Hocko 2017-04-04 7:34 ` Michal Hocko 2017-04-04 8:23 ` Michal Hocko 2017-04-04 8:23 ` Michal Hocko 2017-04-04 15:59 ` Reza Arbab 2017-04-04 15:59 ` Reza Arbab 2017-04-04 16:02 ` Reza Arbab 2017-04-04 16:02 ` Reza Arbab 2017-04-04 16:44 ` Michal Hocko 2017-04-04 16:44 ` Michal Hocko 2017-04-04 18:30 ` Reza Arbab 2017-04-04 18:30 ` Reza Arbab 2017-04-04 19:41 ` Michal Hocko 2017-04-04 19:41 ` Michal Hocko 2017-04-04 21:43 ` Reza Arbab 2017-04-04 21:43 ` Reza Arbab 2017-04-05 6:42 ` Michal Hocko 2017-04-05 6:42 ` Michal Hocko 2017-04-05 9:24 ` Michal Hocko 2017-04-05 9:24 ` Michal Hocko 2017-04-05 14:53 ` Reza Arbab 2017-04-05 14:53 ` Reza Arbab 2017-04-05 15:42 ` Michal Hocko 2017-04-05 15:42 ` Michal Hocko 2017-04-05 17:32 ` Reza Arbab 2017-04-05 17:32 ` Reza Arbab 2017-04-05 18:15 ` Michal Hocko 2017-04-05 18:15 ` Michal Hocko 2017-04-05 19:39 ` Michal Hocko 2017-04-05 19:39 ` Michal Hocko 2017-04-05 21:02 ` Michal Hocko 2017-04-05 21:02 ` Michal Hocko 2017-04-06 11:07 ` Michal Hocko 2017-04-06 11:07 ` Michal Hocko 2017-04-05 15:48 ` Reza Arbab 2017-04-05 15:48 ` Reza Arbab 2017-04-05 16:34 ` Michal Hocko 2017-04-05 16:34 ` Michal Hocko 2017-04-05 20:55 ` Reza Arbab 2017-04-05 20:55 ` Reza Arbab 2017-04-06 9:25 ` Michal Hocko 2017-04-06 9:25 ` Michal Hocko 2017-04-05 13:52 ` Michal Hocko [this message] 2017-04-05 13:52 ` Michal Hocko 2017-04-05 15:23 ` Reza Arbab 2017-04-05 15:23 ` Reza Arbab 2017-04-05 6:36 ` Michal Hocko 2017-04-05 6:36 ` Michal Hocko 2017-04-06 13:08 ` Michal Hocko 2017-04-06 13:08 ` Michal Hocko 2017-04-06 15:24 ` Reza Arbab 2017-04-06 15:24 ` Reza Arbab 2017-04-06 15:41 ` Michal Hocko 2017-04-06 15:41 ` Michal Hocko 2017-04-06 15:46 ` Reza Arbab 2017-04-06 15:46 ` Reza Arbab 2017-04-06 16:21 ` Michal Hocko 2017-04-06 16:21 ` Michal Hocko 2017-04-06 16:24 ` Mel Gorman 2017-04-06 16:24 ` Mel Gorman 2017-04-06 16:55 ` Mel Gorman 2017-04-06 16:55 ` Mel Gorman 2017-04-06 17:12 ` Michal Hocko 2017-04-06 17:12 ` Michal Hocko 2017-04-06 17:46 ` Mel Gorman 2017-04-06 17:46 ` Mel Gorman
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=20170405135248.GQ6035@dhcp22.suse.cz \ --to=mhocko@kernel.org \ --cc=aarcange@redhat.com \ --cc=ak@linux.intel.com \ --cc=akpm@linux-foundation.org \ --cc=arbab@linux.vnet.ibm.com \ --cc=cmetcalf@mellanox.com \ --cc=dan.j.williams@gmail.com \ --cc=daniel.kiper@oracle.com \ --cc=heiko.carstens@de.ibm.com \ --cc=imammedo@redhat.com \ --cc=js1304@gmail.com \ --cc=laijs@cn.fujitsu.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mgorman@suse.de \ --cc=qiuxishi@huawei.com \ --cc=rientjes@google.com \ --cc=schwidefsky@de.ibm.com \ --cc=slaoub@gmail.com \ --cc=tangchen@cn.fujitsu.com \ --cc=toshi.kani@hpe.com \ --cc=vbabka@suse.cz \ --cc=vkuznets@redhat.com \ --cc=yasu.isimatu@gmail.com \ --cc=zhenzhang.zhang@huawei.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: linkBe 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.