linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Zi Yan" <zi.yan@cs.rutgers.edu>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-mm@kvack.org, Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
	"Kirill A. Shutemov" <kirill@shutemov.name>,
	Vlastimil Babka <vbabka@suse.cz>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andrea Reale <ar@linux.vnet.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 3/3] mm: unclutter THP migration
Date: Fri, 29 Dec 2017 10:45:46 -0500	[thread overview]
Message-ID: <044496C5-5ACD-4845-A7A3-BD920BF9233B@cs.rutgers.edu> (raw)
In-Reply-To: <20171229113627.GB27077@dhcp22.suse.cz>

[-- Attachment #1: Type: text/plain, Size: 1956 bytes --]

On 29 Dec 2017, at 6:36, Michal Hocko wrote:

> On Tue 26-12-17 21:19:35, Zi Yan wrote:
>> On 8 Dec 2017, at 11:15, Michal Hocko wrote:
> [...]
>>> @@ -1394,6 +1390,21 @@ int migrate_pages(struct list_head *from, new_page_t get_new_page,
>>>
>>>  			switch(rc) {
>>>  			case -ENOMEM:
>>> +				/*
>>> +				 * THP migration might be unsupported or the
>>> +				 * allocation could've failed so we should
>>> +				 * retry on the same page with the THP split
>>> +				 * to base pages.
>>> +				 */
>>> +				if (PageTransHuge(page)) {
>>> +					lock_page(page);
>>> +					rc = split_huge_page_to_list(page, from);
>>> +					unlock_page(page);
>>> +					if (!rc) {
>>> +						list_safe_reset_next(page, page2, lru);
>>> +						goto retry;
>>> +					}
>>> +				}
>>
>> The hunk splits the THP and adds all tail pages at the end of the list “from”.
>> Why do we need “list_safe_reset_next(page, page2, lru);” here, when page2 is not changed here?
>
> Because we need to handle the case when the page2 was the last on the
> list.

Got it. Thanks for the explanation.

>
>> And it seems a little bit strange to only re-migrate the head page, then come back to all tail
>> pages after migrating the rest of pages in the list “from”. Is it better to split the THP into
>> a list other than “from” and insert the list after “page”, then retry from the split “page”?
>> Thus, we attempt to migrate all sub pages of the THP after it is split.
>
> Why does this matter?

Functionally, it does not matter.

This behavior is just less intuitive and a little different from current one,
which implicitly preserves its original order of the not-migrated pages
in the “from” list, although no one relies on this implicit behavior now.

Adding one line comment about this difference would be good for code maintenance. :)

Reviewed-by: Zi Yan <zi.yan@cs.rutgers.edu>

—
Best Regards,
Yan Zi

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 557 bytes --]

  reply	other threads:[~2017-12-29 15:45 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-07 12:48 [RFC PATCH] " Michal Hocko
2017-12-07 14:10 ` Zi Yan
2017-12-07 14:34   ` Michal Hocko
2017-12-08 16:15     ` [RFC PATCH 0/3] " Michal Hocko
2017-12-08 16:15       ` [RFC PATCH 1/3] mm, numa: rework do_pages_move Michal Hocko
2017-12-13 12:07         ` Kirill A. Shutemov
2017-12-13 12:17           ` Michal Hocko
2017-12-13 12:47             ` Kirill A. Shutemov
2017-12-13 14:10               ` Michal Hocko
2017-12-13 14:27                 ` Kirill A. Shutemov
2017-12-13 14:39         ` Michal Hocko
2017-12-14 15:35           ` Kirill A. Shutemov
2017-12-15  9:28             ` Michal Hocko
2017-12-15  9:51               ` Kirill A. Shutemov
2017-12-15  9:57                 ` Michal Hocko
2018-01-02 11:25         ` Anshuman Khandual
2018-01-02 12:12           ` Michal Hocko
2018-01-03  3:11             ` Anshuman Khandual
2018-01-03  8:42         ` Anshuman Khandual
2018-01-03  8:58           ` Michal Hocko
2018-01-03  9:36             ` Anshuman Khandual
2018-01-03  9:52               ` Michal Hocko
2017-12-08 16:15       ` [RFC PATCH 2/3] mm, migrate: remove reason argument from new_page_t Michal Hocko
2017-12-27  2:12         ` Zi Yan
2017-12-29 11:32           ` Michal Hocko
2017-12-08 16:15       ` [RFC PATCH 3/3] mm: unclutter THP migration Michal Hocko
2017-12-13 12:20         ` Kirill A. Shutemov
2017-12-27  2:19         ` Zi Yan
2017-12-29 11:36           ` Michal Hocko
2017-12-29 15:45             ` Zi Yan [this message]
2017-12-31  9:07               ` Michal Hocko
2017-12-31 13:09                 ` Zi Yan
2017-12-19 12:07       ` [RFC PATCH 0/3] " 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=044496C5-5ACD-4845-A7A3-BD920BF9233B@cs.rutgers.edu \
    --to=zi.yan@cs.rutgers.edu \
    --cc=akpm@linux-foundation.org \
    --cc=ar@linux.vnet.ibm.com \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=vbabka@suse.cz \
    /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