From: Michal Hocko <mhocko@kernel.org> To: Zi Yan <zi.yan@cs.rutgers.edu> 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: Sun, 31 Dec 2017 10:07:10 +0100 [thread overview] Message-ID: <20171231090710.GA18691@dhcp22.suse.cz> (raw) In-Reply-To: <044496C5-5ACD-4845-A7A3-BD920BF9233B@cs.rutgers.edu> On Fri 29-12-17 10:45:46, Zi Yan wrote: > On 29 Dec 2017, at 6:36, Michal Hocko wrote: > > > On Tue 26-12-17 21:19:35, Zi Yan wrote: [...] > >> 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. :) OK, I will not argue. I still do not see _why_ we need it but I've added the following. diff --git a/mm/migrate.c b/mm/migrate.c index 21b3381a2871..0ac5185d3949 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -1395,6 +1395,11 @@ int migrate_pages(struct list_head *from, new_page_t get_new_page, * allocation could've failed so we should * retry on the same page with the THP split * to base pages. + * + * Head page is retried immediatelly and tail + * pages are added to the tail of the list so + * we encounter them after the rest of the list + * is processed. */ if (PageTransHuge(page)) { lock_page(page); Does that this reflect what you mean? > Reviewed-by: Zi Yan <zi.yan@cs.rutgers.edu> Thx! -- Michal Hocko SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org> To: Zi Yan <zi.yan@cs.rutgers.edu> 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: Sun, 31 Dec 2017 10:07:10 +0100 [thread overview] Message-ID: <20171231090710.GA18691@dhcp22.suse.cz> (raw) In-Reply-To: <044496C5-5ACD-4845-A7A3-BD920BF9233B@cs.rutgers.edu> On Fri 29-12-17 10:45:46, Zi Yan wrote: > On 29 Dec 2017, at 6:36, Michal Hocko wrote: > > > On Tue 26-12-17 21:19:35, Zi Yan wrote: [...] > >> 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 a??froma??. Is it better to split the THP into > >> a list other than a??froma?? and insert the list after a??pagea??, then retry from the split a??pagea??? > >> 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 a??froma?? list, although no one relies on this implicit behavior now. > > > Adding one line comment about this difference would be good for code maintenance. :) OK, I will not argue. I still do not see _why_ we need it but I've added the following. diff --git a/mm/migrate.c b/mm/migrate.c index 21b3381a2871..0ac5185d3949 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -1395,6 +1395,11 @@ int migrate_pages(struct list_head *from, new_page_t get_new_page, * allocation could've failed so we should * retry on the same page with the THP split * to base pages. + * + * Head page is retried immediatelly and tail + * pages are added to the tail of the list so + * we encounter them after the rest of the list + * is processed. */ if (PageTransHuge(page)) { lock_page(page); Does that this reflect what you mean? > Reviewed-by: Zi Yan <zi.yan@cs.rutgers.edu> Thx! -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-12-31 9:07 UTC|newest] Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-12-07 12:48 [RFC PATCH] mm: unclutter THP migration Michal Hocko 2017-12-07 12:48 ` Michal Hocko 2017-12-07 14:10 ` Zi Yan 2017-12-07 14:34 ` Michal Hocko 2017-12-07 14:34 ` Michal Hocko 2017-12-08 16:15 ` [RFC PATCH 0/3] " Michal Hocko 2017-12-08 16:15 ` Michal Hocko 2017-12-08 16:15 ` [RFC PATCH 1/3] mm, numa: rework do_pages_move Michal Hocko 2017-12-08 16:15 ` Michal Hocko 2017-12-13 12:07 ` Kirill A. Shutemov 2017-12-13 12:07 ` Kirill A. Shutemov 2017-12-13 12:17 ` Michal Hocko 2017-12-13 12:17 ` Michal Hocko 2017-12-13 12:47 ` Kirill A. Shutemov 2017-12-13 12:47 ` Kirill A. Shutemov 2017-12-13 14:10 ` Michal Hocko 2017-12-13 14:10 ` Michal Hocko 2017-12-13 14:27 ` Kirill A. Shutemov 2017-12-13 14:27 ` Kirill A. Shutemov 2017-12-13 14:39 ` Michal Hocko 2017-12-13 14:39 ` Michal Hocko 2017-12-14 15:35 ` Kirill A. Shutemov 2017-12-14 15:35 ` Kirill A. Shutemov 2017-12-15 9:28 ` Michal Hocko 2017-12-15 9:28 ` Michal Hocko 2017-12-15 9:51 ` Kirill A. Shutemov 2017-12-15 9:51 ` Kirill A. Shutemov 2017-12-15 9:57 ` Michal Hocko 2017-12-15 9:57 ` Michal Hocko 2018-01-02 11:25 ` Anshuman Khandual 2018-01-02 11:25 ` Anshuman Khandual 2018-01-02 12:12 ` Michal Hocko 2018-01-02 12:12 ` Michal Hocko 2018-01-03 3:11 ` Anshuman Khandual 2018-01-03 3:11 ` Anshuman Khandual 2018-01-03 8:42 ` Anshuman Khandual 2018-01-03 8:42 ` Anshuman Khandual 2018-01-03 8:58 ` Michal Hocko 2018-01-03 8:58 ` Michal Hocko 2018-01-03 9:36 ` Anshuman Khandual 2018-01-03 9:36 ` Anshuman Khandual 2018-01-03 9:52 ` Michal Hocko 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-08 16:15 ` Michal Hocko 2017-12-27 2:12 ` Zi Yan 2017-12-29 11:32 ` Michal Hocko 2017-12-29 11:32 ` Michal Hocko 2017-12-08 16:15 ` [RFC PATCH 3/3] mm: unclutter THP migration Michal Hocko 2017-12-08 16:15 ` Michal Hocko 2017-12-13 12:20 ` Kirill A. Shutemov 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 11:36 ` Michal Hocko 2017-12-29 15:45 ` Zi Yan 2017-12-31 9:07 ` Michal Hocko [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 2017-12-19 12:07 ` 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=20171231090710.GA18691@dhcp22.suse.cz \ --to=mhocko@kernel.org \ --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=n-horiguchi@ah.jp.nec.com \ --cc=vbabka@suse.cz \ --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: linkBe 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.