All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: zhong jiang <zhongjiang@huawei.com>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"qiuxishi@huawei.com" <qiuxishi@huawei.com>,
	"vbabka@suse.cz" <vbabka@suse.cz>,
	"mm-commits@vger.kernel.org" <mm-commits@vger.kernel.org>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	Mel Gorman <mgorman@suse.de>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: + mm-hugetlb-fix-race-when-migrate-pages.patch added to -mm tree
Date: Wed, 27 Jul 2016 16:44:05 +0200	[thread overview]
Message-ID: <20160727144400.GB21859@dhcp22.suse.cz> (raw)
In-Reply-To: <57976DE0.8020809@huawei.com>

On Tue 26-07-16 22:04:16, zhong jiang wrote:
> On 2016/7/26 15:58, Michal Hocko wrote:
> > On Fri 22-07-16 07:17:37, Naoya Horiguchi wrote:
> > [...]
> >> I think that (src_pte != dst_pte) can happen and that's ok if there's no
> >> migration entry. 
> > We have discussed that with Naoya off-list and couldn't find a scenario
> > when parent would have !shared pmd while child would have it. The only
> > plausible scenario was that parent created and poppulated mapping smaller
> > than 1G and then enlarged it later on so the child would see sharedable
> > pud. This doesn't seem to be possible because vma_merge would bail out
> > due to VM_SPECIAL check.

> I do not understand that the process must have vm_special flags. if
> vm_special enable, the process must not be expanded. and what does it
> matter about vma_merge ??

See 
	if (vm_flags & VM_SPECIAL)
		return NULL;

in vma_merge.

> >> But even if we have both of normal entry and migration entry
> >> for one hugepage, that still looks fine to me because the running migration
> >> operation fails (because there remains mapcounts on the source hugepage),
> >> and all migration entries are turned back to normal entries pointing to the
> >> source hugepage.
>
> In one case, try_to_unmap_one is first exec and successfully, mapcount
> turn into zero. then we get the pte lock, if src_pte!-dst_pte, it
> maybe lead to the dst_pte is from migrate pte to normal pte, while the
> normal pte turn into migaret pte,, is right ?

I am sorry but I have hard time following your arguments here. Could you
be more specific please?

> > Agreed.
> >
> >> Could you try to see and share what happens on your workload with
> >> Michal's patch?
> >
> > Zhong Jiang did you have chance to retest with the BUG_ON changed?

Anything for this?
-- 
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>

  reply	other threads:[~2016-07-27 14:44 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-19 23:06 + mm-hugetlb-fix-race-when-migrate-pages.patch added to -mm tree akpm
2016-07-21  7:43 ` Michal Hocko
2016-07-21  8:13   ` Naoya Horiguchi
2016-07-21 10:29     ` Michal Hocko
2016-07-21 10:54   ` zhong jiang
2016-07-21 11:27     ` Michal Hocko
2016-07-21 12:14       ` zhong jiang
2016-07-21 12:30         ` Michal Hocko
2016-07-21 12:45           ` zhong jiang
2016-07-21 12:55             ` Michal Hocko
2016-07-21 13:25               ` zhong jiang
2016-07-21 13:40                 ` Michal Hocko
2016-07-21 13:58                   ` zhong jiang
2016-07-21 14:01                     ` Michal Hocko
2016-07-21 14:13                       ` zhong jiang
2016-07-21 14:27                         ` Michal Hocko
2016-07-21 14:33                           ` zhong jiang
2016-07-22  7:17                             ` Naoya Horiguchi
2016-07-26  7:58                               ` Michal Hocko
2016-07-26 14:04                                 ` zhong jiang
2016-07-27 14:44                                   ` Michal Hocko [this message]
2016-07-29 11:27   ` Michal Hocko
2016-07-30  6:33     ` zhong jiang
2016-08-01 11:02       ` Michal Hocko
2016-08-01 15:04         ` zhong jiang
2016-08-01 15:31           ` Michal Hocko
     [not found] <003701d1e328$202ca9d0$6085fd70$@alibaba-inc.com>
2016-07-21  8:19 ` Hillf Danton
2016-07-21  8:19   ` Hillf Danton

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=20160727144400.GB21859@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mike.kravetz@oracle.com \
    --cc=mm-commits@vger.kernel.org \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=qiuxishi@huawei.com \
    --cc=vbabka@suse.cz \
    --cc=zhongjiang@huawei.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.