mm-commits.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: akpm@linux-foundation.org, dan.j.williams@intel.com,
	dave.hansen@linux.intel.com, david@redhat.com,
	gthelen@google.com, linux-mm@kvack.org, mhocko@suse.com,
	mm-commits@vger.kernel.org, oliver.sang@intel.com,
	osalvador@suse.de, rientjes@google.com,
	torvalds@linux-foundation.org, weixugc@google.com,
	yang.shi@linux.alibaba.com, ying.huang@intel.com
Subject: [patch 03/19] mm/migrate: optimize hotplug-time demotion order updates
Date: Mon, 18 Oct 2021 15:15:29 -0700	[thread overview]
Message-ID: <20211018221529.x0SBH6U6i%akpm@linux-foundation.org> (raw)
In-Reply-To: <20211018151438.f2246e2656c041b6753a8bdd@linux-foundation.org>

From: Dave Hansen <dave.hansen@linux.intel.com>
Subject: mm/migrate: optimize hotplug-time demotion order updates

Patch series "mm/migrate: 5.15 fixes for automatic demotion", v2.

This contains two fixes for the "automatic demotion" code which was
merged into 5.15:

 * Fix memory hotplug performance regression by watching
   suppressing any real action on irrelevant hotplug events.
 * Ensure CPU hotplug handler is registered when memory hotplug
   is disabled.


This patch (of 2):

== tl;dr ==

Automatic demotion opted for a simple, lazy approach to handling hotplug
events.  This noticeably slows down memory hotplug[1].  Optimize away
updates to the demotion order when memory hotplug events should have no
effect.

This has no effect on CPU hotplug.  There is no known problem on the CPU
side and any work there will be in a separate series.

== Background ==

Automatic demotion is a memory migration strategy to ensure that new
allocations have room in faster memory tiers on tiered memory systems. 
The kernel maintains an array (node_demotion[]) to drive these migrations.

The node_demotion[] path is calculated by starting at nodes with CPUs and
then "walking" to nodes with memory.  Only hotplug events which online or
offline a node with memory (N_ONLINE) or CPUs (N_CPU) will actually affect
the migration order.

== Problem ==

However, the current code is lazy.  It completely regenerates the
migration order on *any* CPU or memory hotplug event.  The logic was that
these events are extremely rare and that the overhead from indiscriminate
order regeneration is minimal.

Part of the update logic involves a synchronize_rcu(), which is a pretty
big hammer.  Its overhead was large enough to be detected by some 0day
tests that watch memory hotplug performance[1].

== Solution ==

Add a new helper (node_demotion_topo_changed()) which can differentiate
between superfluous and impactful hotplug events.  Skip the expensive
update operation for superfluous events.

== Aside: Locking ==

It took me a few moments to declare the locking to be safe enough for
node_demotion_topo_changed() to work.  It all hinges on the memory hotplug
lock:

During memory hotplug events, 'mem_hotplug_lock' is held for write.  This
ensures that two memory hotplug events can not be called simultaneously.

CPU hotplug has a similar lock (cpuhp_state_mutex) which also provides
mutual exclusion between CPU hotplug events.  In addition, the demotion
code acquire and hold the mem_hotplug_lock for read during its CPU hotplug
handlers.  This provides mutual exclusion between the demotion memory
hotplug callbacks and the CPU hotplug callbacks.

This effectively allows treating the migration target generation code to
act as if it is single-threaded.

1. https://lore.kernel.org/all/20210905135932.GE15026@xsang-OptiPlex-9020/

Link: https://lkml.kernel.org/r/20210924161251.093CCD06@davehans-spike.ostc.intel.com
Link: https://lkml.kernel.org/r/20210924161253.D7673E31@davehans-spike.ostc.intel.com
Fixes: 884a6e5d1f93 ("mm/migrate: update node demotion order on hotplug events")
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reported-by: kernel test robot <oliver.sang@intel.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Cc: "Huang, Ying" <ying.huang@intel.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Wei Xu <weixugc@google.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: David Rientjes <rientjes@google.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: Yang Shi <yang.shi@linux.alibaba.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 mm/migrate.c |   12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

--- a/mm/migrate.c~mm-migrate-optimize-hotplug-time-demotion-order-updates
+++ a/mm/migrate.c
@@ -3239,8 +3239,18 @@ static int migration_offline_cpu(unsigne
  * set_migration_target_nodes().
  */
 static int __meminit migrate_on_reclaim_callback(struct notifier_block *self,
-						 unsigned long action, void *arg)
+						 unsigned long action, void *_arg)
 {
+	struct memory_notify *arg = _arg;
+
+	/*
+	 * Only update the node migration order when a node is
+	 * changing status, like online->offline.  This avoids
+	 * the overhead of synchronize_rcu() in most cases.
+	 */
+	if (arg->status_change_nid < 0)
+		return notifier_from_errno(0);
+
 	switch (action) {
 	case MEM_GOING_OFFLINE:
 		/*
_

  parent reply	other threads:[~2021-10-18 22:15 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-18 22:14 incoming Andrew Morton
2021-10-18 22:15 ` [patch 01/19] mm/userfaultfd: selftests: fix memory corruption with thp enabled Andrew Morton
2021-10-18 22:15 ` [patch 02/19] userfaultfd: fix a race between writeprotect and exit_mmap() Andrew Morton
2021-10-18 22:15 ` Andrew Morton [this message]
2021-10-18 22:15 ` [patch 04/19] mm/migrate: add CPU hotplug to demotion #ifdef Andrew Morton
2021-10-18 22:15 ` [patch 05/19] mm/migrate: fix CPUHP state to update node demotion order Andrew Morton
2021-10-18 22:15 ` [patch 06/19] ocfs2: fix data corruption after conversion from inline format Andrew Morton
2021-10-18 22:15 ` [patch 07/19] ocfs2: mount fails with buffer overflow in strlen Andrew Morton
2021-10-18 22:15 ` [patch 08/19] memblock: check memory total_size Andrew Morton
2021-10-18 22:15 ` [patch 09/19] mm/mempolicy: do not allow illegal MPOL_F_NUMA_BALANCING | MPOL_LOCAL in mbind() Andrew Morton
2021-10-18 22:15 ` [patch 10/19] mm, slub: fix two bugs in slab_debug_trace_open() Andrew Morton
2021-10-18 22:15 ` [patch 11/19] mm, slub: fix mismatch between reconstructed freelist depth and cnt Andrew Morton
2021-10-18 22:15 ` [patch 12/19] mm, slub: fix potential memoryleak in kmem_cache_open() Andrew Morton
2021-10-18 22:16 ` [patch 13/19] mm, slub: fix potential use-after-free in slab_debugfs_fops Andrew Morton
2021-10-18 22:16 ` [patch 14/19] mm, slub: fix incorrect memcg slab count for bulk free Andrew Morton
2021-10-18 22:16 ` [patch 15/19] elfcore: correct reference to CONFIG_UML Andrew Morton
2021-10-18 22:16 ` [patch 16/19] vfs: check fd has read access in kernel_read_file_from_fd() Andrew Morton
2021-10-18 22:16 ` [patch 17/19] mm/secretmem: fix NULL page->mapping dereference in page_is_secretmem() Andrew Morton
2021-10-18 22:16 ` [patch 18/19] mm/thp: decrease nr_thps in file's mapping on THP split Andrew Morton
2021-10-18 22:16 ` [patch 19/19] mailmap: add Andrej Shadura 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:
  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=20211018221529.x0SBH6U6i%akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@redhat.com \
    --cc=gthelen@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=mm-commits@vger.kernel.org \
    --cc=oliver.sang@intel.com \
    --cc=osalvador@suse.de \
    --cc=rientjes@google.com \
    --cc=torvalds@linux-foundation.org \
    --cc=weixugc@google.com \
    --cc=yang.shi@linux.alibaba.com \
    --cc=ying.huang@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).