All of lore.kernel.org
 help / color / mirror / Atom feed
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>

  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: 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.