From: Michal Hocko <mhocko@kernel.org> To: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Michal Hocko <mhocko@suse.com> Subject: [PATCH 1/2] mm, memory_hotplug: fix MMOP_ONLINE_KEEP behavior Date: Wed, 31 May 2017 08:25:45 +0200 [thread overview] Message-ID: <20170531062545.4122-1-mhocko@kernel.org> (raw) In-Reply-To: <20170531062439.GA3853@dhcp22.suse.cz> From: Michal Hocko <mhocko@suse.com> Heiko Carstens has noticed that the MMOP_ONLINE_KEEP is broken currently $ grep . memory3?/valid_zones memory34/valid_zones:Normal Movable memory35/valid_zones:Normal Movable memory36/valid_zones:Normal Movable memory37/valid_zones:Normal Movable $ echo online_movable > memory34/state $ grep . memory3?/valid_zones memory34/valid_zones:Movable memory35/valid_zones:Movable memory36/valid_zones:Movable memory37/valid_zones:Movable $ echo online > memory36/state $ grep . memory3?/valid_zones memory34/valid_zones:Movable memory36/valid_zones:Normal memory37/valid_zones:Movable so we have effectivelly punched a hole into the movable zone. The problem is that move_pfn_range() check for MMOP_ONLINE_KEEP is wrong. It only checks whether the given range is already part of the movable zone which is not the case here as only memory34 is in the zone. Fix this by using allow_online_pfn_range(..., MMOP_ONLINE_KERNEL) if that is false then we can be sure that movable onlining is the right thing to do. Reported-by: Heiko Carstens <heiko.carstens@de.ibm.com> Fixes: "mm, memory_hotplug: do not associate hotadded memory to zones until online" Signed-off-by: Michal Hocko <mhocko@suse.com> --- mm/memory_hotplug.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index 0a895df2397e..b3895fd609f4 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -950,11 +950,12 @@ static struct zone * __meminit move_pfn_range(int online_type, int nid, if (online_type == MMOP_ONLINE_KEEP) { struct zone *movable_zone = &pgdat->node_zones[ZONE_MOVABLE]; /* - * MMOP_ONLINE_KEEP inherits the current zone which is - * ZONE_NORMAL by default but we might be within ZONE_MOVABLE - * already. + * MMOP_ONLINE_KEEP defaults to MMOP_ONLINE_KERNEL but use + * movable zone if that is not possible (e.g. we are within + * or past the existing movable zone) */ - if (zone_intersects(movable_zone, start_pfn, nr_pages)) + if (!allow_online_pfn_range(nid, start_pfn, nr_pages, + MMOP_ONLINE_KERNEL)) zone = movable_zone; } else if (online_type == MMOP_ONLINE_MOVABLE) { zone = &pgdat->node_zones[ZONE_MOVABLE]; -- 2.11.0
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org> To: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Michal Hocko <mhocko@suse.com> Subject: [PATCH 1/2] mm, memory_hotplug: fix MMOP_ONLINE_KEEP behavior Date: Wed, 31 May 2017 08:25:45 +0200 [thread overview] Message-ID: <20170531062545.4122-1-mhocko@kernel.org> (raw) In-Reply-To: <20170531062439.GA3853@dhcp22.suse.cz> From: Michal Hocko <mhocko@suse.com> Heiko Carstens has noticed that the MMOP_ONLINE_KEEP is broken currently $ grep . memory3?/valid_zones memory34/valid_zones:Normal Movable memory35/valid_zones:Normal Movable memory36/valid_zones:Normal Movable memory37/valid_zones:Normal Movable $ echo online_movable > memory34/state $ grep . memory3?/valid_zones memory34/valid_zones:Movable memory35/valid_zones:Movable memory36/valid_zones:Movable memory37/valid_zones:Movable $ echo online > memory36/state $ grep . memory3?/valid_zones memory34/valid_zones:Movable memory36/valid_zones:Normal memory37/valid_zones:Movable so we have effectivelly punched a hole into the movable zone. The problem is that move_pfn_range() check for MMOP_ONLINE_KEEP is wrong. It only checks whether the given range is already part of the movable zone which is not the case here as only memory34 is in the zone. Fix this by using allow_online_pfn_range(..., MMOP_ONLINE_KERNEL) if that is false then we can be sure that movable onlining is the right thing to do. Reported-by: Heiko Carstens <heiko.carstens@de.ibm.com> Fixes: "mm, memory_hotplug: do not associate hotadded memory to zones until online" Signed-off-by: Michal Hocko <mhocko@suse.com> --- mm/memory_hotplug.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index 0a895df2397e..b3895fd609f4 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -950,11 +950,12 @@ static struct zone * __meminit move_pfn_range(int online_type, int nid, if (online_type == MMOP_ONLINE_KEEP) { struct zone *movable_zone = &pgdat->node_zones[ZONE_MOVABLE]; /* - * MMOP_ONLINE_KEEP inherits the current zone which is - * ZONE_NORMAL by default but we might be within ZONE_MOVABLE - * already. + * MMOP_ONLINE_KEEP defaults to MMOP_ONLINE_KERNEL but use + * movable zone if that is not possible (e.g. we are within + * or past the existing movable zone) */ - if (zone_intersects(movable_zone, start_pfn, nr_pages)) + if (!allow_online_pfn_range(nid, start_pfn, nr_pages, + MMOP_ONLINE_KERNEL)) zone = movable_zone; } else if (online_type == MMOP_ONLINE_MOVABLE) { zone = &pgdat->node_zones[ZONE_MOVABLE]; -- 2.11.0 -- 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-05-31 6:25 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-05-24 8:20 [-next] memory hotplug regression Heiko Carstens 2017-05-24 8:20 ` Heiko Carstens 2017-05-24 8:39 ` Michal Hocko 2017-05-24 8:39 ` Michal Hocko 2017-05-26 12:25 ` Heiko Carstens 2017-05-26 12:25 ` Heiko Carstens 2017-05-29 8:52 ` Michal Hocko 2017-05-29 8:52 ` Michal Hocko 2017-05-29 10:11 ` Heiko Carstens 2017-05-29 10:11 ` Heiko Carstens 2017-05-29 10:45 ` Michal Hocko 2017-05-29 10:45 ` Michal Hocko 2017-05-30 12:18 ` Michal Hocko 2017-05-30 12:18 ` Michal Hocko 2017-05-30 12:37 ` Heiko Carstens 2017-05-30 12:37 ` Heiko Carstens 2017-05-30 14:32 ` Michal Hocko 2017-05-30 14:32 ` Michal Hocko 2017-05-30 14:55 ` Heiko Carstens 2017-05-30 14:55 ` Heiko Carstens 2017-05-30 15:04 ` Michal Hocko 2017-05-30 15:04 ` Michal Hocko 2017-05-31 6:24 ` Michal Hocko 2017-05-31 6:24 ` Michal Hocko 2017-05-31 6:25 ` Michal Hocko [this message] 2017-05-31 6:25 ` [PATCH 1/2] mm, memory_hotplug: fix MMOP_ONLINE_KEEP behavior Michal Hocko 2017-05-31 6:26 ` [PATCH 2/2] mm, memory_hotplug: do not assume ZONE_NORMAL is default kernel zone Michal Hocko 2017-05-31 6:26 ` Michal Hocko 2017-06-01 6:49 ` [-next] memory hotplug regression Heiko Carstens 2017-06-01 6:49 ` Heiko Carstens 2017-06-01 7:13 ` Michal Hocko 2017-06-01 7:13 ` Michal Hocko 2017-06-01 8:37 [PATCH 0/2] memory hotplug follow up fixes Michal Hocko 2017-06-01 8:37 ` [PATCH 1/2] mm, memory_hotplug: fix MMOP_ONLINE_KEEP behavior Michal Hocko 2017-06-01 8:37 ` Michal Hocko 2017-06-01 12:32 ` Vlastimil Babka 2017-06-01 12:32 ` Vlastimil Babka 2017-06-01 12:40 ` Michal Hocko 2017-06-01 12:40 ` Michal Hocko
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=20170531062545.4122-1-mhocko@kernel.org \ --to=mhocko@kernel.org \ --cc=gerald.schaefer@de.ibm.com \ --cc=heiko.carstens@de.ibm.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mhocko@suse.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.