All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Andrey Gruzdev <andrey.gruzdev@virtuozzo.com>
Cc: Peter Krempa <pkrempa@redhat.com>,
	Juan Quintela <quintela@redhat.com>,
	qemu-devel@nongnu.org, Peter Xu <peterx@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>, Den Lunev <den@openvz.org>
Subject: Re: [PATCH v4 0/6] UFFD write-tracking migration/snapshots
Date: Tue, 1 Dec 2020 18:40:55 +0000	[thread overview]
Message-ID: <20201201184055.GM4338@work-vm> (raw)
In-Reply-To: <d3b0c767-14d8-b7e7-345d-0314acb3d07e@virtuozzo.com>

* Andrey Gruzdev (andrey.gruzdev@virtuozzo.com) wrote:
> On 01.12.2020 13:53, Peter Krempa wrote:
> > On Tue, Dec 01, 2020 at 11:42:18 +0300, Andrey Gruzdev wrote:
> > > On 01.12.2020 10:08, Peter Krempa wrote:
> > > > On Thu, Nov 26, 2020 at 18:17:28 +0300, Andrey Gruzdev via wrote:
> > > > > This patch series is a kind of 'rethinking' of Denis Plotnikov's ideas he's
> > 
> > [...]
> > 
> > > > Note that in cases when qemu can't guarantee that the
> > > > background_snapshot feature will work it should not advertise it. We
> > > > need a way to check whether it's possible to use it, so we can replace
> > > > the existing --live flag with it rather than adding a new one and
> > > > shifting the problem of checking whether the feature works to the user.
> > > > 
> > > 
> > > Hi,
> > > 
> > > May be you are using hugetlbfs as memory backend?
> > 
> > Not exactly hugepages, but I had:
> > 
> >    <memoryBacking>
> >      <access mode='shared'/>
> >    </memoryBacking>
> > 
> > which resulted into the following commandline to instantiate memory:
> > 
> > -object memory-backend-file,id=pc.ram,mem-path=/var/lib/libvirt/qemu/ram/6-upstream-bj/pc.ram,share=yes,size=33554432000,host-nodes=0,policy=bind \
> > 
> > When I've removed it I got:
> > 
> > -object memory-backend-ram,id=pc.ram,size=33554432000,host-nodes=0,policy=bind \
> > 
> > And the migration didn't fail in my quick test. I'll have a more
> > detailed look later, thanks for the pointer.
> > 
> 
> Yep, seems that current userfaultfd supports hugetlbfs and shared memory for
> missing pages but not for wr-protected..

For hugepages, you'd need kernel support - but also you'd want to make
sure you write the whole hugepage at once.

For shared, there's a harder problem to ask; what happens if RAM is
written by the other process - for postcopy, we get the other process
to send us a userfaultfd that they have registered with their VM.

Dave

> > > I totally agree that we need somehow check that kernel and VM memory backend
> > > support the feature before one can enable the capability.
> > > Need to think about that..
> > 
> > Definitely. Also note that memory backed by memory-backend-file will be
> > more and more common, for cases such as virtiofs DAX sharing and
> > similar.
> > 
> 
> I see.. That needs support from kernel side, so far 'background-snapshots'
> are incompatible with memory-backend-file sharing.
> 
> -- 
> Andrey Gruzdev, Principal Engineer
> Virtuozzo GmbH  +7-903-247-6397
>                 virtuzzo.com
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK



  reply	other threads:[~2020-12-01 18:42 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-26 15:17 [PATCH v4 0/6] UFFD write-tracking migration/snapshots Andrey Gruzdev via
2020-11-26 15:17 ` [PATCH v4 1/6] introduce 'background-snapshot' migration capability Andrey Gruzdev via
2020-11-27 19:55   ` Peter Xu
2020-11-28 16:35     ` Andrey Gruzdev
2020-11-26 15:17 ` [PATCH v4 2/6] introduce UFFD-WP low-level interface helpers Andrey Gruzdev via
2020-11-27 21:04   ` Peter Xu
2020-11-29 20:12     ` Andrey Gruzdev
2020-11-30 15:34       ` Peter Xu
2020-11-30 18:41         ` Andrey Gruzdev
2020-12-01 12:24   ` Dr. David Alan Gilbert
2020-12-01 19:32     ` Andrey Gruzdev
2020-11-26 15:17 ` [PATCH v4 3/6] support UFFD write fault processing in ram_save_iterate() Andrey Gruzdev via
2020-11-27 21:49   ` Peter Xu
2020-11-29 21:14     ` Andrey Gruzdev
2020-11-30 16:32       ` Peter Xu
2020-11-30 19:27         ` Andrey Gruzdev
2020-11-26 15:17 ` [PATCH v4 4/6] implementation of background snapshot thread Andrey Gruzdev via
2020-11-26 15:17 ` [PATCH v4 5/6] the rest of write tracking migration code Andrey Gruzdev via
2020-11-27 22:26   ` Peter Xu
2020-11-30  8:09     ` Andrey Gruzdev
2020-11-26 15:17 ` [PATCH v4 6/6] introduce simple linear scan rate limiting mechanism Andrey Gruzdev via
2020-11-27 22:28   ` Peter Xu
2020-11-30  8:11     ` Andrey Gruzdev
2020-11-30 16:40       ` Peter Xu
2020-11-30 19:30         ` Andrey Gruzdev
2020-11-26 15:47 ` [PATCH v4 0/6] UFFD write-tracking migration/snapshots Peter Krempa
2020-11-27  8:21   ` Andrey Gruzdev
2020-11-27  9:49     ` Peter Krempa
2020-11-27 10:00       ` Andrey Gruzdev
2020-11-27 15:45         ` Peter Xu
2020-11-27 17:19           ` Andrey Gruzdev
2020-11-27 22:04 ` Peter Xu
2020-11-30  8:07   ` Andrey Gruzdev
2020-12-01  7:08 ` Peter Krempa
2020-12-01  8:42   ` Andrey Gruzdev
2020-12-01 10:53     ` Peter Krempa
2020-12-01 11:24       ` Andrey Gruzdev
2020-12-01 18:40         ` Dr. David Alan Gilbert [this message]
2020-12-01 19:22           ` Peter Xu
2020-12-01 20:01             ` Dr. David Alan Gilbert
2020-12-01 20:29               ` Andrey Gruzdev
2020-12-01 20:11           ` Andrey Gruzdev
2020-12-01 18:54         ` Peter Xu
2020-12-01 20:00           ` Dr. David Alan Gilbert
2020-12-01 20:26           ` Andrey Gruzdev

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=20201201184055.GM4338@work-vm \
    --to=dgilbert@redhat.com \
    --cc=andrey.gruzdev@virtuozzo.com \
    --cc=armbru@redhat.com \
    --cc=den@openvz.org \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=pkrempa@redhat.com \
    --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 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.