From: Andrea Reale <ar@linux.vnet.ibm.com>
To: linux-kernel@vger.kernel.org, zi.yan@cs.rutgers.edu,
n-horiguchi@ah.jp.nec.com
Cc: akpm@linux-foundation.org, jglisse@redhat.com, realean2@ie.ibm.com
Subject: [PATCH 0/1] mm/migrate: do not call prep_transhuge_page if !thp_migration_supported
Date: Mon, 20 Nov 2017 16:17:29 +0000 [thread overview]
Message-ID: <cover.1511193197.git.ar@linux.vnet.ibm.com> (raw)
Hi all,
While working on a second round of patches to introduce memory hotplug /
hot remove to arm64 (original attempt at [1]), and trying to rebase them
on 4.14, I stumbled in some problematic behaviour during page migration
when offlining for hot remove, whereas target pages for migration where
found in a bad state.
I believe that this behaviour may be originating from commit 8135d8926c08
("mm: memory_hotplug: memory hotremove supports thp migration")
and it is triggered when migrating pages for builds that have no
ARCH_ENABLE_THP_MIGRATION but have thp support on (arm64, in my case).
Specifically, my understanding is that prep_transhuge_page should not be
called in linux/migrate.h:new_page_nodemask if !thp_migration_supported
because, in that case, new_page would not be a thp.
A tiny patch follows, showing what I mean. Please, let me know if my
understanding is bogus.
Best regards,
Andrea
[1] https://lkml.org/lkml/2017/4/11/536
Andrea Reale (1):
mm/migrate: do not call prep_transhuge_page if
!thp_migration_supported
include/linux/migrate.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.7.4
next reply other threads:[~2017-11-20 16:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-20 16:17 Andrea Reale [this message]
2017-11-20 16:17 ` [PATCH 1/1] mm/migrate: do not call prep_transhuge_page if !thp_migration_supported Andrea Reale
2017-11-20 16:33 ` Zi Yan
2017-11-20 17:07 ` Andrea Reale
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=cover.1511193197.git.ar@linux.vnet.ibm.com \
--to=ar@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=jglisse@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=realean2@ie.ibm.com \
--cc=zi.yan@cs.rutgers.edu \
/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.