From: Peter Xu <peterx@redhat.com>
To: Alexey Perevalov <a.perevalov@samsung.com>
Cc: qemu-devel@nongnu.org, i.maximets@samsung.com,
quintela@redhat.com, heetae82.ahn@samsung.com,
dgilbert@redhat.com
Subject: Re: [Qemu-devel] [PATCH v8 3/3] migration: add bitmap for received page
Date: Wed, 26 Jul 2017 16:43:23 +0800 [thread overview]
Message-ID: <20170726084323.GL1595@pxdev.xzpeter.org> (raw)
In-Reply-To: <19a15ce5-5427-c85b-f194-c3eb6740aef3@samsung.com>
On Wed, Jul 26, 2017 at 11:07:17AM +0300, Alexey Perevalov wrote:
> On 07/26/2017 04:49 AM, Peter Xu wrote:
> >On Thu, Jul 20, 2017 at 09:52:34AM +0300, Alexey Perevalov wrote:
> >>This patch adds ability to track down already received
> >>pages, it's necessary for calculation vCPU block time in
> >>postcopy migration feature, maybe for restore after
> >>postcopy migration failure.
> >>Also it's necessary to solve shared memory issue in
> >>postcopy livemigration. Information about received pages
> >>will be transferred to the software virtual bridge
> >>(e.g. OVS-VSWITCHD), to avoid fallocate (unmap) for
> >>already received pages. fallocate syscall is required for
> >>remmaped shared memory, due to remmaping itself blocks
> >>ioctl(UFFDIO_COPY, ioctl in this case will end with EEXIT
> >>error (struct page is exists after remmap).
> >>
> >>Bitmap is placed into RAMBlock as another postcopy/precopy
> >>related bitmaps.
> >>
> >>Reviewed-by: Peter Xu <peterx@redhat.com>
> >>Signed-off-by: Alexey Perevalov <a.perevalov@samsung.com>
> >>---
> >[...]
> >
> >> static int qemu_ufd_copy_ioctl(int userfault_fd, void *host_addr,
> >>- void *from_addr, uint64_t pagesize)
> >>+ void *from_addr, uint64_t pagesize, RAMBlock *rb)
> >> {
> >>+ int ret;
> >> if (from_addr) {
> >> struct uffdio_copy copy_struct;
> >> copy_struct.dst = (uint64_t)(uintptr_t)host_addr;
> >> copy_struct.src = (uint64_t)(uintptr_t)from_addr;
> >> copy_struct.len = pagesize;
> >> copy_struct.mode = 0;
> >>- return ioctl(userfault_fd, UFFDIO_COPY, ©_struct);
> >>+ ret = ioctl(userfault_fd, UFFDIO_COPY, ©_struct);
> >> } else {
> >> struct uffdio_zeropage zero_struct;
> >> zero_struct.range.start = (uint64_t)(uintptr_t)host_addr;
> >> zero_struct.range.len = pagesize;
> >> zero_struct.mode = 0;
> >>- return ioctl(userfault_fd, UFFDIO_ZEROPAGE, &zero_struct);
> >>+ ret = ioctl(userfault_fd, UFFDIO_ZEROPAGE, &zero_struct);
> >>+ }
> >>+ if (!ret) {
> >>+ ramblock_recv_bitmap_set(host_addr, rb);
> >Wait...
> >
> >Now we are using 4k-page/bit bitmap, do we need to take care of the
> >huge pages here? Looks like we are only setting the first bit of it
> >if it is a huge page?
> First version was per ramblock page size, IOW bitmap was smaller in
> case of hugepages.
Yes, but this is not the first version any more. :)
This patch is using:
bitmap_new(rb->max_length >> TARGET_PAGE_BITS);
to allocate bitmap, so it is using small pages always for bitmap,
right? (I should not really say "4k" pages, here I think the size is
host page size, which is the thing returned from getpagesize()).
>
>
> You mentioned that TARGET_PAGE_SIZE is reasonable for precopy case,
> in "Re: [Qemu-devel] [PATCH v1 2/2] migration: add bitmap for copied page"
> I though TARGET_PAGE_SIZE as transmition unit, is using in precopy even
> hugepage case.
> But it's not so logically, page being marked as dirty, should be sent as a
> whole page.
Sorry if I misunderstood, but I didn't see anything wrong - we are
sending pages in small pages, but when postcopy is there, we do
UFFDIO_COPY in huge page, so everything is fine?
--
Peter Xu
next prev parent reply other threads:[~2017-07-26 8:43 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20170720065246eucas1p1fb290bf54218503c2eb59db1c472faeb@eucas1p1.samsung.com>
2017-07-20 6:52 ` [Qemu-devel] [PATCH v8 0/3] Add bitmap for received pages in postcopy migration Alexey Perevalov
[not found] ` <CGME20170720065248eucas1p233be1718f190cd4415c0e58a23e2ef2a@eucas1p2.samsung.com>
2017-07-20 6:52 ` [Qemu-devel] [PATCH v8 1/3] migration: postcopy_place_page factoring out Alexey Perevalov
[not found] ` <CGME20170720065248eucas1p1641d5e3f9f3d6cc3849f9345006d3bb6@eucas1p1.samsung.com>
2017-07-20 6:52 ` [Qemu-devel] [PATCH v8 2/3] migration: introduce qemu_ufd_copy_ioctl helper Alexey Perevalov
[not found] ` <CGME20170720065249eucas1p2cc3e779e2cde2125f90ae25ff03ac646@eucas1p2.samsung.com>
2017-07-20 6:52 ` [Qemu-devel] [PATCH v8 3/3] migration: add bitmap for received page Alexey Perevalov
2017-07-26 1:49 ` Peter Xu
2017-07-26 8:07 ` Alexey Perevalov
2017-07-26 8:43 ` Peter Xu [this message]
2017-07-26 15:24 ` Alexey Perevalov
2017-07-27 2:35 ` Peter Xu
2017-07-27 7:27 ` Alexey Perevalov
2017-07-28 4:27 ` Peter Xu
2017-07-28 6:43 ` Alexey Perevalov
2017-07-28 6:57 ` Peter Xu
2017-07-28 7:06 ` Alexey Perevalov
2017-07-28 15:29 ` Alexey Perevalov
2017-07-31 1:33 ` Peter Xu
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=20170726084323.GL1595@pxdev.xzpeter.org \
--to=peterx@redhat.com \
--cc=a.perevalov@samsung.com \
--cc=dgilbert@redhat.com \
--cc=heetae82.ahn@samsung.com \
--cc=i.maximets@samsung.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 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).