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

Groups > linux.kernel > #1561449 > unrolled thread

Re: [PATCH v6 kernel 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v6 kernel 0/5] Extend virtio-balloon for fast  (de)inflating & fast live migration David Hildenbrand <david@redhat.com> - 2017-01-18 11:20 +0100
    RE: [PATCH v6 kernel 0/5] Extend virtio-balloon for fast  (de)inflating & fast live migration "Li, Liang Z" <liang.z.li@intel.com> - 2017-01-18 14:40 +0100
    Re: [PATCH v6 kernel 0/5] Extend virtio-balloon for fast  (de)inflating & fast live migration "Michael S. Tsirkin" <mst@redhat.com> - 2017-01-18 16:40 +0100
      Re: [PATCH v6 kernel 0/5] Extend virtio-balloon for fast  (de)inflating & fast live migration David Hildenbrand <david@redhat.com> - 2017-01-19 18:50 +0100

#1561449 — Re: [PATCH v6 kernel 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

Am 21.12.2016 um 07:52 schrieb Liang Li:
> 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 {pfn|length} to present
> the page information 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 unused 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 unused page information in a
> {pfn|length} array and send it to host with the virt queue of
> virtio-balloon. For an idle guest with 8GB RAM, this can help to shorten
> the total live migration time from 2Sec to about 500ms in 10Gbps network
> environment. For an guest with quite a lot of page cache and with little
> unused pages, it's possible to let the guest drop it's page cache before
> live migration, this case can benefit from this new feature too.

I agree that both changes make sense (although the second change just 
smells very racy, as you also pointed out in the patch description),
however I am not sure if virtio-balloon is really the right place for
the latter change.

virtio-balloon is all about ballooning, nothing else. What you're doing
is using it as a way to communicate balloon-unrelated data from/to the
hypervisor. Yes, it is also about guest memory, but completely unrelated
to the purpose of the balloon device.

Maybe using virtio-balloon for this purpose is okay - I have mixed
feelings (especially as I can't tell where else this could go). I would
like to get a second opinion on this.

-- 

David

[toc] | [next] | [standalone]

#1561802

> Am 21.12.2016 um 07:52 schrieb Liang Li:
> > 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 {pfn|length} to present
> > the page information 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 unused 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 unused page information
> > in a {pfn|length} array and send it to host with the virt queue of
> > virtio-balloon. For an idle guest with 8GB RAM, this can help to
> > shorten the total live migration time from 2Sec to about 500ms in
> > 10Gbps network environment. For an guest with quite a lot of page
> > cache and with little unused pages, it's possible to let the guest
> > drop it's page cache before live migration, this case can benefit from this
> new feature too.
> 
> I agree that both changes make sense (although the second change just
> smells very racy, as you also pointed out in the patch description), however I
> am not sure if virtio-balloon is really the right place for the latter change.
> 
> virtio-balloon is all about ballooning, nothing else. What you're doing is using
> it as a way to communicate balloon-unrelated data from/to the hypervisor.
> Yes, it is also about guest memory, but completely unrelated to the purpose
> of the balloon device.
> 
> Maybe using virtio-balloon for this purpose is okay - I have mixed feelings
> (especially as I can't tell where else this could go). I would like to get a second
> opinion on this.
> 

We have ever discussed the implementation for a long time, making use the current
virtio balloon seems better than the other solutions and is recommended by Michael.

Thanks!
Liang
> --
> 
> David

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

#1561900

On Wed, Jan 18, 2017 at 11:09:30AM +0100, David Hildenbrand wrote:
> Am 21.12.2016 um 07:52 schrieb Liang Li:
> > 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 {pfn|length} to present
> > the page information 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 unused 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 unused page information in a
> > {pfn|length} array and send it to host with the virt queue of
> > virtio-balloon. For an idle guest with 8GB RAM, this can help to shorten
> > the total live migration time from 2Sec to about 500ms in 10Gbps network
> > environment. For an guest with quite a lot of page cache and with little
> > unused pages, it's possible to let the guest drop it's page cache before
> > live migration, this case can benefit from this new feature too.
> 
> I agree that both changes make sense (although the second change just smells
> very racy, as you also pointed out in the patch description),
> however I am not sure if virtio-balloon is really the right place for
> the latter change.
> 
> virtio-balloon is all about ballooning, nothing else. What you're doing
> is using it as a way to communicate balloon-unrelated data from/to the
> hypervisor. Yes, it is also about guest memory, but completely unrelated
> to the purpose of the balloon device.
> 
> Maybe using virtio-balloon for this purpose is okay - I have mixed
> feelings (especially as I can't tell where else this could go). I would
> like to get a second opinion on this.

As long as the interface is similar, it seems to make
sense for me - why invent a completely new device that
looks very much like the old one?

So this boils down to whether the speedup patches are merged.


> -- 
> 
> David

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

#1562974

> As long as the interface is similar, it seems to make
> sense for me - why invent a completely new device that
> looks very much like the old one?

The only reason would be that this feature could be used independently
of virtio-balloon. But this would of course only be the case, if
ballooning is strictly not wanted in a configuration, or the current
balloon driver gets replaced by an alternative solution.

I don't have any strong feelings about this, just wanted to double check.

Thanks,

David

> 
> So this boils down to whether the speedup patches are merged.
> 
> 
>> -- 
>>
>> David

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web