linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
To: Zi Yan <zi.yan@cs.rutgers.edu>
Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com>,
	Zi Yan <zi.yan@sent.com>,
	"kirill.shutemov@linux.intel.com"
	<kirill.shutemov@linux.intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"minchan@kernel.org" <minchan@kernel.org>,
	"vbabka@suse.cz" <vbabka@suse.cz>,
	"mgorman@techsingularity.net" <mgorman@techsingularity.net>,
	"mhocko@kernel.org" <mhocko@kernel.org>,
	"dnellans@nvidia.com" <dnellans@nvidia.com>
Subject: Re: [PATCH v5 08/11] mm: hwpoison: soft offline supports thp migration
Date: Thu, 27 Apr 2017 04:41:13 +0000	[thread overview]
Message-ID: <20170427044112.GA18781@hori1.linux.bs1.fc.nec.co.jp> (raw)
In-Reply-To: <58FA2B85.5040904@cs.rutgers.edu>

On Fri, Apr 21, 2017 at 10:55:49AM -0500, Zi Yan wrote:
> 
> 
> Anshuman Khandual wrote:
> > On 04/21/2017 02:17 AM, Zi Yan wrote:
> >> From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> >>
> >> This patch enables thp migration for soft offline.
> >>
> >> Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> >>
> >> ChangeLog: v1 -> v5:
> >> - fix page isolation counting error
> >>
> >> Signed-off-by: Zi Yan <zi.yan@cs.rutgers.edu>
> >> ---
> >>  mm/memory-failure.c | 35 ++++++++++++++---------------------
> >>  1 file changed, 14 insertions(+), 21 deletions(-)
> >>
> >> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> >> index 9b77476ef31f..23ff02eb3ed4 100644
> >> --- a/mm/memory-failure.c
> >> +++ b/mm/memory-failure.c
> >> @@ -1481,7 +1481,17 @@ static struct page *new_page(struct page *p, unsigned long private, int **x)
> >>  	if (PageHuge(p))
> >>  		return alloc_huge_page_node(page_hstate(compound_head(p)),
> >>  						   nid);
> >> -	else
> >> +	else if (thp_migration_supported() && PageTransHuge(p)) {
> >> +		struct page *thp;
> >> +
> >> +		thp = alloc_pages_node(nid,
> >> +			(GFP_TRANSHUGE | __GFP_THISNODE) & ~__GFP_RECLAIM,
> > 
> > Why not __GFP_RECLAIM ? Its soft offline path we wait a bit before
> > declaring that THP page cannot be allocated and hence should invoke
> > reclaim methods as well.
> 
> I am not sure how much effort the kernel wants to put here to soft
> offline a THP. Naoya knows more here.

What I thought at first was that soft offline is not an urgent user
and no need to reclaim (i.e. give a little impact on other thread.)
But that's not a strong opinion, so if you like __GFP_RECLAIM here,
I'm fine about that.

> 
> 
> > 
> >> +			HPAGE_PMD_ORDER);
> >> +		if (!thp)
> >> +			return NULL;
> >> +		prep_transhuge_page(thp);
> >> +		return thp;
> >> +	} else
> >>  		return __alloc_pages_node(nid, GFP_HIGHUSER_MOVABLE, 0);
> >>  }
> >>  
> >> @@ -1665,8 +1675,8 @@ static int __soft_offline_page(struct page *page, int flags)
> >>  		 * cannot have PAGE_MAPPING_MOVABLE.
> >>  		 */
> >>  		if (!__PageMovable(page))
> >> -			inc_node_page_state(page, NR_ISOLATED_ANON +
> >> -						page_is_file_cache(page));
> >> +			mod_node_page_state(page_pgdat(page), NR_ISOLATED_ANON +
> >> +						page_is_file_cache(page), hpage_nr_pages(page));
> >>  		list_add(&page->lru, &pagelist);
> >>  		ret = migrate_pages(&pagelist, new_page, NULL, MPOL_MF_MOVE_ALL,
> >>  					MIGRATE_SYNC, MR_MEMORY_FAILURE);
> >> @@ -1689,28 +1699,11 @@ static int __soft_offline_page(struct page *page, int flags)
> >>  static int soft_offline_in_use_page(struct page *page, int flags)
> >>  {
> >>  	int ret;
> >> -	struct page *hpage = compound_head(page);
> >> -
> >> -	if (!PageHuge(page) && PageTransHuge(hpage)) {
> >> -		lock_page(hpage);
> >> -		if (!PageAnon(hpage) || unlikely(split_huge_page(hpage))) {
> >> -			unlock_page(hpage);
> >> -			if (!PageAnon(hpage))
> >> -				pr_info("soft offline: %#lx: non anonymous thp\n", page_to_pfn(page));
> >> -			else
> >> -				pr_info("soft offline: %#lx: thp split failed\n", page_to_pfn(page));
> >> -			put_hwpoison_page(hpage);
> >> -			return -EBUSY;
> >> -		}
> >> -		unlock_page(hpage);
> >> -		get_hwpoison_page(page);
> >> -		put_hwpoison_page(hpage);
> >> -	}
> >>  
> >>  	if (PageHuge(page))
> >>  		ret = soft_offline_huge_page(page, flags);
> >>  	else
> >> -		ret = __soft_offline_page(page, flags);
> >> +		ret = __soft_offline_page(compound_head(page), flags);
> > 
> > Hmm, what if the THP allocation fails in the new_page() path and
> > we fallback for general page allocation. In that case we will
> > always be still calling with the head page ? Because we dont
> > split the huge page any more.
> 
> This could be a problem if the user wants to offline a TailPage but due
> to THP allocation failure, the HeadPage is offlined.

Right, "retry with split" part is unfinished, so we need some improvement.

> 
> It may be better to only soft offline THPs if page ==
> compound_head(page). If page != compound_head(page), we still split THPs
> like before.
> 
> Because in migrate_pages(), we cannot guarantee any TailPages in that
> THP are migrated (1. THP allocation failure causes THP splitting, then
> only HeadPage is going to be migrated; 2. even if we change existing
> migrate_pages() implementation to add all TailPages to migration list
> instead of LRU list, we still cannot guarantee the TailPage we want to
> migrate is migrated.).
> 
> Naoya, what do you think?

Maybe soft offline is a special caller of page migration because it
basically wants to migrate only one page, but thp migration still has
a benefit because we can avoid thp split.
So I like that we try thp migration at first, and if it fails we fall
back to split and migrate (only) a raw error page. This should be done
in caller side for soft offline, because it knows where the error page is.

As for generic case (for other migration callers which mainly want to
migrate multiple pages for their purpose,) thp split and retry can be
done in common migration code. After thp split, all subpages are linked
to migration list, then we retry without returning to the caller.
So I think that split_huge_page() can be moved to (for example) for-loop
in migrate_pages().

I tried to write a patch for it last year, but considering vm event
accounting, the patch might be large (~100 lines).

Thanks,
Naoya Horiguchi
--
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>

  reply	other threads:[~2017-04-27  4:44 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-20 20:47 [PATCH v5 00/11] mm: page migration enhancement for thp Zi Yan
2017-04-20 20:47 ` [PATCH v5 01/11] mm: x86: move _PAGE_SWP_SOFT_DIRTY from bit 7 to bit 1 Zi Yan
2017-05-19 13:07   ` Anshuman Khandual
2017-05-19 15:55   ` Dave Hansen
2017-05-19 16:31     ` Zi Yan
2017-05-19 16:36       ` Dave Hansen
2017-04-20 20:47 ` [PATCH v5 02/11] mm: mempolicy: add queue_pages_node_check() Zi Yan
2017-04-21  4:04   ` Anshuman Khandual
2017-05-19 13:13     ` Anshuman Khandual
2017-05-19 16:02       ` Mel Gorman
2017-05-19 16:37         ` Zi Yan
2017-05-19 20:28           ` Mel Gorman
2017-05-19 20:48             ` Zi Yan
2017-05-19 21:39               ` Mel Gorman
2017-04-20 20:47 ` [PATCH v5 03/11] mm: thp: introduce separate TTU flag for thp freezing Zi Yan
2017-04-21  4:29   ` Anshuman Khandual
2017-04-20 20:47 ` [PATCH v5 04/11] mm: thp: introduce CONFIG_ARCH_ENABLE_THP_MIGRATION Zi Yan
2017-04-21  4:36   ` Anshuman Khandual
2017-04-20 20:47 ` [PATCH v5 05/11] mm: thp: enable thp migration in generic path Zi Yan
2017-04-20 20:47 ` [PATCH v5 06/11] mm: thp: check pmd migration entry in common path Zi Yan
2017-04-21  6:17   ` Anshuman Khandual
2017-04-21 15:17     ` Zi Yan
2017-04-20 20:47 ` [PATCH v5 07/11] mm: soft-dirty: keep soft-dirty bits over thp migration Zi Yan
2017-04-20 20:47 ` [PATCH v5 08/11] mm: hwpoison: soft offline supports " Zi Yan
2017-04-21  8:10   ` Anshuman Khandual
2017-04-21 15:55     ` Zi Yan
2017-04-27  4:41       ` Naoya Horiguchi [this message]
2017-04-27 16:39         ` Zi Yan
2017-04-20 20:47 ` [PATCH v5 09/11] mm: mempolicy: mbind and migrate_pages support " Zi Yan
2017-04-21  8:22   ` Anshuman Khandual
2017-04-21 16:00     ` Zi Yan
2017-04-20 20:47 ` [PATCH v5 10/11] mm: migrate: move_pages() supports " Zi Yan
2017-04-20 20:47 ` [PATCH v5 11/11] mm: memory_hotplug: memory hotremove " Zi Yan
2017-05-19 13:56   ` Anshuman Khandual

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=20170427044112.GA18781@hori1.linux.bs1.fc.nec.co.jp \
    --to=n-horiguchi@ah.jp.nec.com \
    --cc=akpm@linux-foundation.org \
    --cc=dnellans@nvidia.com \
    --cc=khandual@linux.vnet.ibm.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@kernel.org \
    --cc=minchan@kernel.org \
    --cc=vbabka@suse.cz \
    --cc=zi.yan@cs.rutgers.edu \
    --cc=zi.yan@sent.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