All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@redhat.com>
To: Wei Wang <wei.w.wang@intel.com>
Cc: qemu-devel@nongnu.org, virtio-dev@lists.oasis-open.org,
	mst@redhat.com, dgilbert@redhat.com, pbonzini@redhat.com,
	liliang.opensource@gmail.com, yang.zhang.wz@gmail.com,
	quan.xu0@gmail.com, nilal@redhat.com, riel@redhat.com
Subject: Re: [Qemu-devel] [PATCH v1 1/4] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ
Date: Wed, 17 Jan 2018 12:40:38 +0100	[thread overview]
Message-ID: <878tcw4ssp.fsf@secure.laptop> (raw)
In-Reply-To: <1516170720-4948-2-git-send-email-wei.w.wang@intel.com> (Wei Wang's message of "Wed, 17 Jan 2018 14:31:57 +0800")

Wei Wang <wei.w.wang@intel.com> wrote:
> The new feature enables the virtio-balloon device to receive the hint of
> guest free pages from the free page vq, and clears the corresponding bits
> of the free page from the dirty bitmap, so that those free pages are not
> transferred by the migration thread.
>
> Without this feature, to local live migrate an 8G idle guest takes
> ~2286 ms. With this featrue, it takes ~260 ms, which redues the
> migration time to ~11%.
>
> Signed-off-by: Wei Wang <wei.w.wang@intel.com>
> Signed-off-by: Liang Li <liang.z.li@intel.com>
> CC: Michael S. Tsirkin <mst@redhat.com>

I don't claim to understandthe full balloon driver


> diff --git a/migration/ram.c b/migration/ram.c
> index cb1950f..d6f462c 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -2186,6 +2186,16 @@ static int ram_init_all(RAMState **rsp)
>      return 0;
>  }
>  
> +void skip_free_pages_from_dirty_bitmap(RAMBlock *block, ram_addr_t offset,
> +                                       size_t len)
> +{
> +    long start = offset >> TARGET_PAGE_BITS,
> +         nr = len >> TARGET_PAGE_BITS;
> +
> +    bitmap_clear(block->bmap, start, nr);

But what assures us that all the nr pages are dirty?


> +    ram_state->migration_dirty_pages -= nr;

This should be
ram_state->migration_dirty_pages -=
     count_ones(block->bmap, start, nr);

For a count_ones function, no?

Furthermore, we have one "optimization" and this only works for the
second stages onward:

static inline
unsigned long migration_bitmap_find_dirty(RAMState *rs, RAMBlock *rb,
                                          unsigned long start)
{
    unsigned long size = rb->used_length >> TARGET_PAGE_BITS;
    unsigned long *bitmap = rb->bmap;
    unsigned long next;

    if (rs->ram_bulk_stage && start > 0) {
        next = start + 1;
    } else {
        next = find_next_bit(bitmap, size, start);
    }

    return next;
}

So, for making this really work, we have more work to do.

Actually, what I think we should do was to _ask_ the guest which pages
are used at the beggining, instead of just setting all pages as dirty,
but that requires kernel changes and lot of search of corner cases.

Later, Juan.

  reply	other threads:[~2018-01-17 11:40 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-17  6:31 [virtio-dev] [PATCH v1 0/4] virtio-balloon: support free page reporting Wei Wang
2018-01-17  6:31 ` [Qemu-devel] " Wei Wang
2018-01-17  6:31 ` [virtio-dev] [PATCH v1 1/4] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ Wei Wang
2018-01-17  6:31   ` [Qemu-devel] " Wei Wang
2018-01-17 11:40   ` Juan Quintela [this message]
2018-01-17 15:52     ` [virtio-dev] " Wang, Wei W
2018-01-17 15:52       ` Wang, Wei W
2018-01-17 12:31   ` Juan Quintela
2018-01-19  3:52     ` [virtio-dev] " Wei Wang
2018-01-19  3:52       ` [Qemu-devel] " Wei Wang
2018-01-17  6:31 ` [virtio-dev] [PATCH v1 2/4] migration: call balloon to clear bits of free pages from dirty bitmap Wei Wang
2018-01-17  6:31   ` [Qemu-devel] " Wei Wang
2018-01-17  6:31 ` [virtio-dev] [PATCH v1 3/4] virtio-balloon: add a timer to limit the free page report wating time Wei Wang
2018-01-17  6:31   ` [Qemu-devel] " Wei Wang
2018-01-17  6:32 ` [virtio-dev] [PATCH v1 4/4] virtio-balloon: Don't skip free pages if the poison val is non-zero Wei Wang
2018-01-17  6:32   ` [Qemu-devel] " Wei Wang

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=878tcw4ssp.fsf@secure.laptop \
    --to=quintela@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=liliang.opensource@gmail.com \
    --cc=mst@redhat.com \
    --cc=nilal@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quan.xu0@gmail.com \
    --cc=riel@redhat.com \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=wei.w.wang@intel.com \
    --cc=yang.zhang.wz@gmail.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.