linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrea Arcangeli <aarcange@redhat.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: kirill.shutemov@linux.intel.com, "Li,
	Liang Z" <liang.z.li@intel.com>, Amit Shah <amit.shah@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"quintela@redhat.com" <quintela@redhat.com>,
	linux-mm@kvack.org
Subject: Re: post-copy is broken?
Date: Thu, 14 Apr 2016 12:22:30 -0400	[thread overview]
Message-ID: <20160414162230.GC9976@redhat.com> (raw)
In-Reply-To: <20160414123441.GF2252@work-vm>

Adding linux-mm too,

On Thu, Apr 14, 2016 at 01:34:41PM +0100, Dr. David Alan Gilbert wrote:
> * Andrea Arcangeli (aarcange@redhat.com) wrote:
> 
> > The next suspect is the massive THP refcounting change that went
> > upstream recently:
> 
> > As further debug hint, can you try to disable THP and see if that
> > makes the problem go away?
> 
> Yep, this seems to be the problem (cc'ing in Kirill).
> 
> 122afea9626ab3f717b250a8dd3d5ebf57cdb56c - works (just before Kirill disables THP)
> 61f5d698cc97600e813ca5cf8e449b1ea1c11492 - breaks (when THP is reenabled)
> 
> It's pretty reliable; as you say disabling THP makes it work again
> and putting it back to THP/madvise mode makes it break.  And you need
> to test on a machine with some free ram to make sure THP has a chance
> to have happened.
> 
> I'm not sure of all of the rework that happened in that series,
> but my reading of it is that splitting of THP pages gets deferred;
> so I wonder if when I do the madvise to turn THP off, if it's actually
> still got THP pages and thus we end up with a whole THP mapped
> when I'm expecting to be userfaulting those pages.

Good thing at least I didn't make UFFDIO_COPY THP aware yet so there's
less variables (as no user was interested to handle userfaults at THP
granularity yet, and from userland such an improvement would be
completely invisible in terms of API, so if an user starts doing that
we can just optimize the kernel for it, criu restore could do that as
the faults will come from disk-I/O, when network is involved THP
userfaults wouldn't have a great tradeoff with regard to the increased
fault latency).

I suspect there is an handle_userfault missing somewhere in connection
with trans_huge_pmd splits (not anymore THP splits) that you're doing
with MADV_DONTNEED to zap those pages in the destination that got
redirtied in source during the last precopy stage. Or more simply
MADV_DONTNEED isn't zapping all the right ptes after the trans huge
pmd got splitted.

The fact the page isn't splitted shouldn't matter too much, all we care
about is the pte triggers handle_userfault after MADV_DONTNEED.

The userfaultfd testcase in the kernel isn't exercising this case
unfortunately, that should probably be improved too, so there is a
simpler way to reproduce than running precopy before postcopy in qemu.

Thanks,
Andrea

--
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-04-14 16:22 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <F2CBF3009FA73547804AE4C663CAB28E0417E6B1@shsmsx102.ccr.corp.intel.com>
     [not found] ` <20160412175501.GB6415@work-vm>
     [not found]   ` <F2CBF3009FA73547804AE4C663CAB28E0417EE92@shsmsx102.ccr.corp.intel.com>
     [not found]     ` <F2CBF3009FA73547804AE4C663CAB28E0417EEE4@shsmsx102.ccr.corp.intel.com>
     [not found]       ` <20160413080545.GA2270@work-vm>
     [not found]         ` <20160413114103.GB2270@work-vm>
     [not found]           ` <20160413125053.GC2270@work-vm>
     [not found]             ` <20160413205132.GG26364@redhat.com>
     [not found]               ` <20160414123441.GF2252@work-vm>
2016-04-14 16:22                 ` Andrea Arcangeli [this message]
2016-04-15 12:52                   ` post-copy is broken? Kirill A. Shutemov
2016-04-15 13:42                     ` Dr. David Alan Gilbert
2016-04-15 15:23                       ` Kirill A. Shutemov
2016-04-15 16:34                         ` Dr. David Alan Gilbert
2016-04-18  9:50                           ` Li, Liang Z
2016-04-18  9:55                             ` Dr. David Alan Gilbert
2016-04-18 10:06                               ` Li, Liang Z
2016-04-18 10:15                                 ` Dr. David Alan Gilbert
2016-04-18 10:33                                   ` Li, Liang Z
2016-04-18 13:23                                     ` Dr. David Alan Gilbert
2016-04-18 17:18                                       ` Dr. David Alan Gilbert
2016-04-20 17:27                                     ` Dr. David Alan Gilbert
2016-04-21 19:21                                       ` Dr. David Alan Gilbert
2016-04-27 14:47                                     ` Andrea Arcangeli
2016-04-28  2:59                                       ` Li, Liang Z
2016-04-28  8:03                                         ` Dr. David Alan Gilbert
2016-04-15 22:19                         ` Andrea Arcangeli
2016-04-18  9:40                           ` Dr. David Alan Gilbert
2016-04-18  9:58                             ` Li, Liang Z

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=20160414162230.GC9976@redhat.com \
    --to=aarcange@redhat.com \
    --cc=amit.shah@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=liang.z.li@intel.com \
    --cc=linux-mm@kvack.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.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;
as well as URLs for NNTP newsgroup(s).