From: "Zi Yan" <zi.yan@cs.rutgers.edu>
To: Michal Hocko <mhocko@kernel.org>
Cc: "Naoya Horiguchi" <n-horiguchi@ah.jp.nec.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
"Andrea Reale" <ar@linux.vnet.ibm.com>,
"Jérôme Glisse" <jglisse@redhat.com>,
stable@vger.kernel.org,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [PATCH] mm: migrate: fix an incorrect call of prep_transhuge_page()
Date: Wed, 22 Nov 2017 07:13:37 -0500 [thread overview]
Message-ID: <896594C0-D9CE-4E95-BCAF-45BAD3E3DA2C@cs.rutgers.edu> (raw)
In-Reply-To: <20171122101422.ny5tyyyje5dhx343@dhcp22.suse.cz>
[-- Attachment #1: Type: text/plain, Size: 2324 bytes --]
On 22 Nov 2017, at 5:14, Michal Hocko wrote:
> On Wed 22-11-17 10:35:10, Michal Hocko wrote:
> [...]
>> Moreover I am not really sure this is really working properly. Just look
>> at the split_huge_page. It moves all the tail pages to the LRU list
>> while migrate_pages has a list of pages to migrate. So we will migrate
>> the head page and all the rest will get back to the LRU list. What
>> guarantees that they will get migrated as well.
>
> OK, so this is as I've expected. It doesn't work! Some pfn walker based
> migration will just skip tail pages see madvise_inject_error.
> __alloc_contig_migrate_range will simply fail on THP page see
> isolate_migratepages_block so we even do not try to migrate it.
> do_move_page_to_node_array will simply migrate head and do not care
> about tail pages. do_mbind splits the page and then fall back to pte
> walk when thp migration is not supported but it doesn't handle tail
> pages if the THP migration path is not able to allocate a fresh THP
> AFAICS. Memory hotplug should be safe because it doesn't skip the whole
> THP when doing pfn walk.
>
> Unless I am missing something here this looks like a huge mess to me.
+Kirill
First, I agree with you that splitting a THP and only migrating its head page
is a mess. But what you describe is also the behavior of migrate_page()
_before_ THP migration support is added. I thought that was intended.
Look at http://elixir.free-electrons.com/linux/v4.13.15/source/mm/migrate.c#L1091,
unmap_and_move() splits THPs and only migrates the head page in v4.13 before THP
migration is added. I think the behavior was introduced since v4.5 (I just skimmed
v4.0 to v4.13 code and did not have time to use git blame), before that THPs are
not migrated but shown as successfully migrated (at least from v4.4’s code).
Naoya and I had a discussion on this ‘splitting a THP and migrating its head page’ before.
We think we should try to spilt the THP and migrate all its subpages. I did not have
time to get the code out yet.
I am traveling today, so I may not be able to do anything useful. I will be on a break
for a month and will not have good accesses to any machines. I can try to fix
this ‘splitting a THP and migrating its head page’ after that.
—
Best Regards,
Yan Zi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 557 bytes --]
next prev parent reply other threads:[~2017-11-22 12:13 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-21 2:18 Zi Yan
2017-11-21 22:12 ` Andrew Morton
2017-11-21 22:35 ` Zi Yan
2017-11-22 9:43 ` Andrea Reale
2017-11-22 8:54 ` Michal Hocko
2017-11-22 9:18 ` Zi Yan
2017-11-22 9:35 ` Michal Hocko
2017-11-22 10:14 ` Michal Hocko
2017-11-22 12:13 ` Zi Yan [this message]
2017-11-22 12:29 ` Zi Yan
2017-11-22 13:01 ` Michal Hocko
2017-11-22 13:40 ` Michal Hocko
2017-11-22 14:43 ` Zi Yan
2017-11-22 14:53 ` Michal Hocko
2017-11-22 15:09 ` Zi Yan
2017-11-22 15:39 ` 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=896594C0-D9CE-4E95-BCAF-45BAD3E3DA2C@cs.rutgers.edu \
--to=zi.yan@cs.rutgers.edu \
--cc=akpm@linux-foundation.org \
--cc=ar@linux.vnet.ibm.com \
--cc=jglisse@redhat.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=stable@vger.kernel.org \
/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