Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1457575 > unrolled thread

[PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration

Back to article view | Back to linux.kernel

Contents

  [PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration  Liang Li <liang.z.li@intel.com> - 2016-08-08 08:50 +0200
    Re: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast  (de)inflating & fast live migration Dave Hansen <dave.hansen@intel.com> - 2016-08-08 18:20 +0200
      RE: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast  (de)inflating & fast live migration "Li, Liang Z" <liang.z.li@intel.com> - 2016-08-09 05:00 +0200

#1457575 — [PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration

This patch set contains two parts of changes to the virtio-balloon. 

One is the change for speeding up the inflating & deflating process,
the main idea of this optimization is to use bitmap to send the page
information to host instead of the PFNs, to reduce the overhead of
virtio data transmission, address translation and madvise(). This can
help to improve the performance by about 85%.

Another change is for speeding up live migration. By skipping process
guest's free pages in the first round of data copy, to reduce needless
data processing, this can help to save quite a lot of CPU cycles and
network bandwidth. We put guest's free page information in bitmap and
send it to host with the virt queue of virtio-balloon. For an idle 8GB
guest, this can help to shorten the total live migration time from 2Sec
to about 500ms in the 10Gbps network environment.  

Dave Hansen suggested a new scheme to encode the data structure,
because of additional complexity, it's not implemented in v3.

Changes from v2 to v3:
    * Change the name of 'free page' to 'unused page'.
    * Use the scatter & gather bitmap instead of a 1MB page bitmap. 
    * Fix overwriting the page bitmap after kicking. 
    * Some of MST's comments for v2. 

Changes from v1 to v2:
    * Abandon the patch for dropping page cache.
    * Put some structures to uapi head file.
    * Use a new way to determine the page bitmap size.
    * Use a unified way to send the free page information with the bitmap 
    * Address the issues referred in MST's comments


Liang Li (7):
  virtio-balloon: rework deflate to add page to a list
  virtio-balloon: define new feature bit and page bitmap head
  mm: add a function to get the max pfn
  virtio-balloon: speed up inflate/deflate process
  mm: add the related functions to get unused page
  virtio-balloon: define feature bit and head for misc virt queue
  virtio-balloon: tell host vm's unused page info

 drivers/virtio/virtio_balloon.c     | 390 ++++++++++++++++++++++++++++++++----
 include/linux/mm.h                  |   3 +
 include/uapi/linux/virtio_balloon.h |  41 ++++
 mm/page_alloc.c                     |  94 +++++++++
 4 files changed, 485 insertions(+), 43 deletions(-)

-- 
1.8.3.1

[toc] | [next] | [standalone]

#1457888 — Re: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration

On 08/07/2016 11:35 PM, Liang Li wrote:
> Dave Hansen suggested a new scheme to encode the data structure,
> because of additional complexity, it's not implemented in v3.

FWIW, I don't think it takes any additional complexity here, at least in
the guest implementation side.  The thing I suggested would just mean
explicitly calling out that there was a single bitmap instead of
implying it in the ABI.

Do you think the scheme I suggested is the way to go?

[toc] | [prev] | [next] | [standalone]

#1458377 — RE: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration

> Subject: Re: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating
> & fast live migration
> 
> On 08/07/2016 11:35 PM, Liang Li wrote:
> > Dave Hansen suggested a new scheme to encode the data structure,
> > because of additional complexity, it's not implemented in v3.
> 
> FWIW, I don't think it takes any additional complexity here, at least in the
> guest implementation side.  The thing I suggested would just mean explicitly
> calling out that there was a single bitmap instead of implying it in the ABI.
> 
> Do you think the scheme I suggested is the way to go?

Yes, I think so.  And I will do that in the later version. In this V3, I just want to solve the 
issue caused by a large page bitmap in v2.

Liang

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web