archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <>
Subject: [patch 2/5] drivers/base/memory.c: indicate all memory blocks as removable
Date: Sat, 28 Mar 2020 19:17:19 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

From: David Hildenbrand <>
Subject: drivers/base/memory.c: indicate all memory blocks as removable

We see multiple issues with the implementation/interface to compute
whether a memory block can be offlined (exposed via
/sys/devices/system/memory/memoryX/removable) and would like to simplify
it (remove the implementation).

1. It runs basically lockless. While this might be good for performance,
   we see possible races with memory offlining that will require at least
   some sort of locking to fix.

2. Nowadays, more false positives are possible. No arch-specific checks
   are performed that validate if memory offlining will not be denied
   right away (and such check will require locking). For example, arm64
   won't allow to offline any memory block that was added during boot -
   which will imply a very high error rate. Other archs have other

3. The interface is inherently racy. E.g., if a memory block is
   detected to be removable (and was not a false positive at that time),
   there is still no guarantee that offlining will actually succeed. So
   any caller already has to deal with false positives.

4. It is unclear which performance benefit this interface actually
   provides. The introducing commit 5c755e9fd813 ("memory-hotplug: add
   sysfs removable attribute for hotplug memory remove") mentioned
	"A user-level agent must be able to identify which sections of
	 memory are likely to be removable before attempting the
	 potentially expensive operation."
   However, no actual performance comparison was included.

Known users:
- lsmem: Will group memory blocks based on the "removable" property. [1]
- chmem: Indirect user. It has a RANGE mode where one can specify
	 removable ranges identified via lsmem to be offlined. However, it
	 also has a "SIZE" mode, which allows a sysadmin to skip the manual
	 "identify removable blocks" step. [2]
- powerpc-utils: Uses the "removable" attribute to skip some memory
		 blocks right away when trying to find some to
		 offline+remove. However, with ballooning enabled, it
		 already skips this information completely (because it
		 once resulted in many false negatives). Therefore, the
		 implementation can deal with false positives properly
		 already. [3]

According to Nathan Fontenot, DLPAR on powerpc is nowadays no longer
driven from userspace via the drmgr command (powerpc-utils). Nowadays
it's managed in the kernel - including onlining/offlining of memory
blocks - triggered by drmgr writing to /sys/kernel/dlpar. So the
affected legacy userspace handling is only active on old kernels. Only ve=
old versions of drmgr on a new kernel (unlikely) might execute slower -
totally acceptable.

With CONFIG_MEMORY_HOTREMOVE, always indicating "removable" should not
break any user space tool. We implement a very bad heuristic now.  Withou=
CONFIG_MEMORY_HOTREMOVE we cannot offline anything, so report
"not removable" as before.

Original discussion can be found in [4] ("[PATCH RFC v1] mm:
is_mem_section_removable() overhaul").

Other users of is_mem_section_removable() will be removed next, so that
we can remove is_mem_section_removable() completely.


Also, this patch probably fixes a crash reported by Steve.

Signed-off-by: David Hildenbrand <>
Suggested-by: Michal Hocko <>
Acked-by: Michal Hocko <>
Reviewed-by: Nathan Fontenot <>
Reported-by: "Scargall, Steve" <>
Cc: Dan Williams <>
Cc: Greg Kroah-Hartman <>
Cc: "Rafael J. Wysocki" <>
Cc: Badari Pulavarty <>
Cc: Robert Jennings <>
Cc: Heiko Carstens <>
Cc: Karel Zak <>
Cc: <>
Signed-off-by: Andrew Morton <>

 drivers/base/memory.c |   23 +++--------------------
 1 file changed, 3 insertions(+), 20 deletions(-)

--- a/drivers/base/memory.c~drivers-base-memoryc-indicate-all-memory-blocks-as-removable
+++ a/drivers/base/memory.c
@@ -97,30 +97,13 @@ static ssize_t phys_index_show(struct de
- * Show whether the memory block is likely to be offlineable (or is already
- * offline). Once offline, the memory block could be removed. The return
- * value does, however, not indicate that there is a way to remove the
- * memory block.
+ * Legacy interface that we cannot remove. Always indicate "removable"
+ * with CONFIG_MEMORY_HOTREMOVE - bad heuristic.
 static ssize_t removable_show(struct device *dev, struct device_attribute *attr,
 			      char *buf)
-	struct memory_block *mem = to_memory_block(dev);
-	unsigned long pfn;
-	int ret = 1, i;
-	if (mem->state != MEM_ONLINE)
-		goto out;
-	for (i = 0; i < sections_per_block; i++) {
-		if (!present_section_nr(mem->start_section_nr + i))
-			continue;
-		pfn = section_nr_to_pfn(mem->start_section_nr + i);
-		ret &= is_mem_section_removable(pfn, PAGES_PER_SECTION);
-	}
-	return sprintf(buf, "%d\n", ret);
+	return sprintf(buf, "%d\n", (int)IS_ENABLED(CONFIG_MEMORY_HOTREMOVE));

  parent reply	other threads:[~2020-03-29  2:17 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-29  2:14 incoming Andrew Morton
2020-03-29  2:17 ` [patch 1/5] mm/swapfile.c: move inode_lock out of claim_swapfile Andrew Morton
2020-03-29  2:17 ` Andrew Morton [this message]
2020-03-29 16:46   ` [patch 2/5] drivers/base/memory.c: indicate all memory blocks as removable Linus Torvalds
2020-03-29 18:03     ` David Hildenbrand
2020-03-29 18:28       ` Linus Torvalds
2020-03-29 19:11         ` David Hildenbrand
2020-03-29 19:15           ` Linus Torvalds
2020-03-29 19:43       ` Konstantin Ryabitsev
2020-03-29 19:55         ` Linus Torvalds
2020-03-29 19:56           ` Linus Torvalds
2020-03-30 14:46           ` Konstantin Ryabitsev
2020-03-30 14:54         ` David Hildenbrand
2020-04-01 13:35           ` David Hildenbrand
2020-04-01 15:33             ` Konstantin Ryabitsev
2020-04-01 15:40               ` David Hildenbrand
2020-03-29  2:17 ` [patch 3/5] hugetlb_cgroup: fix illegal access to memory Andrew Morton
2020-03-29  2:17 ` [patch 4/5] mm: fork: fix kernel_stack memcg stats for various stack implementations Andrew Morton
2020-03-29 16:41   ` Linus Torvalds
2020-03-29  2:17 ` [patch 5/5] mm/sparse: fix kernel crash with pfn_section_valid check Andrew Morton

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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).