From: Mel Gorman <mgorman@techsingularity.net>
To: Punit Agrawal <punit.agrawal@arm.com>
Cc: akpm@linux-foundation.org, cl@linux.com, iamjoonsoo.kim@lge.com,
manoj.iyer@canonical.com, n-horiguchi@ah.jp.nec.com,
stable@vger.kernel.org, wanpeng.li@hotmail.com,
mm-commits@vger.kernel.org
Subject: Re: + mm-migrate-fix-ref-count-handling-when-hugepage_migration_supported-v2.patch added to -mm tree
Date: Fri, 26 May 2017 16:33:02 +0100 [thread overview]
Message-ID: <20170526153302.3n3v4rzajx5dkzdq@techsingularity.net> (raw)
In-Reply-To: <87bmqfd61m.fsf@e105922-lin.cambridge.arm.com>
On Fri, May 26, 2017 at 03:52:21PM +0100, Punit Agrawal wrote:
> > I've never looked too closely at how hardware poisoning and hugetlb pages
> > migration is handled so I could easily have missed something but this
> > changelog and patch confuses me.
> >
> > Surely if the inconsistency is between hugepage_migration_supported and
> > !hugepage_migration_supported then the check in soft_offline_huge_page()
> > should also be related to hugepage_migration_supported either in
> > soft_offline_huge_page() or in putback_movable_pages()?
>
> The first version of the patch did indeed make a change that was around
> !hugepage_migration_supported() [0] which was effectively a revert of
> 32665f2bbfed ("mm/migrate: correct failure handling if
> !hugepage_migration_support()").
>
> But Horiguchi-san suggested that dropping the putback_active_hugepage()
> from unmap_and_move_hugepage() will bring back the issue that
> 32665f2bbfed addressed it was safer to take the current approach. It
> also matches the pattern followed for !hugepage.
>
> I did update the changelog but perhaps not enough - would updating the
> changelog to reflect this help make it clearer?
>
Ok, I see what the patch is doing now. I don't think you need to alter
the changelog as I think the patch is ok.
Thanks for clarifying.
--
Mel Gorman
SUSE Labs
prev parent reply other threads:[~2017-05-26 15:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-25 22:46 + mm-migrate-fix-ref-count-handling-when-hugepage_migration_supported-v2.patch added to -mm tree akpm
2017-05-26 5:41 ` Naoya Horiguchi
2017-05-26 9:22 ` Punit Agrawal
2017-05-26 10:42 ` Mel Gorman
2017-05-26 14:52 ` Punit Agrawal
2017-05-26 15:33 ` Mel Gorman [this message]
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=20170526153302.3n3v4rzajx5dkzdq@techsingularity.net \
--to=mgorman@techsingularity.net \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=manoj.iyer@canonical.com \
--cc=mm-commits@vger.kernel.org \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=punit.agrawal@arm.com \
--cc=stable@vger.kernel.org \
--cc=wanpeng.li@hotmail.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 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.