All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Liang Li <liang.z.li@intel.com>, kvm@vger.kernel.org
Cc: virtio-dev@lists.oasis-open.org, qemu-devel@nongnu.org,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, amit.shah@redhat.com,
	dave.hansen@intel.com, cornelia.huck@de.ibm.com,
	pbonzini@redhat.com, mst@redhat.com, aarcange@redhat.com,
	dgilbert@redhat.com, quintela@redhat.com
Subject: Re: [PATCH v6 kernel 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration
Date: Wed, 18 Jan 2017 11:09:30 +0100	[thread overview]
Message-ID: <2a32f616-25a8-ba5a-f74c-d619fc8ab333@redhat.com> (raw)
In-Reply-To: <1482303148-22059-1-git-send-email-liang.z.li@intel.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: David Hildenbrand <david@redhat.com>
To: Liang Li <liang.z.li@intel.com>, kvm@vger.kernel.org
Cc: aarcange@redhat.com, virtio-dev@lists.oasis-open.org,
	dave.hansen@intel.com, linux-kernel@vger.kernel.org,
	mst@redhat.com, qemu-devel@nongnu.org,
	virtualization@lists.linux-foundation.org, linux-mm@kvack.org,
	amit.shah@redhat.com, pbonzini@redhat.com, dgilbert@redhat.com
Subject: Re: [PATCH v6 kernel 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration
Date: Wed, 18 Jan 2017 11:09:30 +0100	[thread overview]
Message-ID: <2a32f616-25a8-ba5a-f74c-d619fc8ab333@redhat.com> (raw)
In-Reply-To: <1482303148-22059-1-git-send-email-liang.z.li@intel.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: David Hildenbrand <david@redhat.com>
To: Liang Li <liang.z.li@intel.com>, kvm@vger.kernel.org
Cc: virtio-dev@lists.oasis-open.org, qemu-devel@nongnu.org,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, amit.shah@redhat.com,
	dave.hansen@intel.com, cornelia.huck@de.ibm.com,
	pbonzini@redhat.com, mst@redhat.com, aarcange@redhat.com,
	dgilbert@redhat.com, quintela@redhat.com
Subject: Re: [PATCH v6 kernel 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration
Date: Wed, 18 Jan 2017 11:09:30 +0100	[thread overview]
Message-ID: <2a32f616-25a8-ba5a-f74c-d619fc8ab333@redhat.com> (raw)
In-Reply-To: <1482303148-22059-1-git-send-email-liang.z.li@intel.com>

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: David Hildenbrand <david@redhat.com>
To: Liang Li <liang.z.li@intel.com>, kvm@vger.kernel.org
Cc: virtio-dev@lists.oasis-open.org, qemu-devel@nongnu.org,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, amit.shah@redhat.com,
	dave.hansen@intel.com, cornelia.huck@de.ibm.com,
	pbonzini@redhat.com, mst@redhat.com, aarcange@redhat.com,
	dgilbert@redhat.com, quintela@redhat.com
Subject: Re: [Qemu-devel] [PATCH v6 kernel 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration
Date: Wed, 18 Jan 2017 11:09:30 +0100	[thread overview]
Message-ID: <2a32f616-25a8-ba5a-f74c-d619fc8ab333@redhat.com> (raw)
In-Reply-To: <1482303148-22059-1-git-send-email-liang.z.li@intel.com>

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

  parent reply	other threads:[~2017-01-18 10:17 UTC|newest]

Thread overview: 100+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-21  6:52 [PATCH v6 kernel 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration Liang Li
2016-12-21  6:52 ` [Qemu-devel] " Liang Li
2016-12-21  6:52 ` Liang Li
2016-12-21  6:52 ` Liang Li
2016-12-21  6:52 ` [PATCH v6 kernel 1/5] virtio-balloon: rework deflate to add page to a list Liang Li
2016-12-21  6:52   ` [Qemu-devel] " Liang Li
2016-12-21  6:52   ` Liang Li
2016-12-21  6:52 ` Liang Li
2016-12-21  6:52 ` [PATCH v6 kernel 2/5] virtio-balloon: define new feature bit and head struct Liang Li
2016-12-21  6:52   ` [Qemu-devel] " Liang Li
2016-12-21  6:52   ` Liang Li
2017-01-12 19:43   ` Michael S. Tsirkin
2017-01-12 19:43   ` Michael S. Tsirkin
2017-01-12 19:43     ` [Qemu-devel] " Michael S. Tsirkin
2017-01-12 19:43     ` Michael S. Tsirkin
2017-01-13  9:24     ` [virtio-dev] " Li, Liang Z
2017-01-13  9:24       ` [Qemu-devel] " Li, Liang Z
2017-01-13  9:24       ` Li, Liang Z
2017-01-17 19:11       ` Michael S. Tsirkin
2017-01-17 19:11         ` [Qemu-devel] " Michael S. Tsirkin
2017-01-17 19:11         ` Michael S. Tsirkin
2017-01-18  1:55         ` Li, Liang Z
2017-01-18  1:55         ` Li, Liang Z
2017-01-18  1:55           ` [Qemu-devel] " Li, Liang Z
2017-01-18  1:55           ` Li, Liang Z
2017-01-18 15:30           ` Michael S. Tsirkin
2017-01-18 15:30           ` Michael S. Tsirkin
2017-01-18 15:30             ` [Qemu-devel] " Michael S. Tsirkin
2017-01-18 15:30             ` Michael S. Tsirkin
2017-01-18 15:30             ` Michael S. Tsirkin
2017-01-19  1:30             ` [virtio-dev] " Li, Liang Z
2017-01-19  1:30               ` [Qemu-devel] " Li, Liang Z
2017-01-19  1:30               ` Li, Liang Z
2017-01-19  1:30               ` Li, Liang Z
2017-01-19  1:30             ` [virtio-dev] " Li, Liang Z
2017-01-17 19:11       ` Michael S. Tsirkin
2017-01-13  9:24     ` Li, Liang Z
2016-12-21  6:52 ` Liang Li
2016-12-21  6:52 ` [PATCH v6 kernel 3/5] virtio-balloon: speed up inflate/deflate process Liang Li
2016-12-21  6:52   ` [Qemu-devel] " Liang Li
2016-12-21  6:52   ` Liang Li
2017-01-17 19:15   ` Michael S. Tsirkin
2017-01-17 19:15     ` [Qemu-devel] " Michael S. Tsirkin
2017-01-17 19:15     ` Michael S. Tsirkin
2017-01-18  4:56     ` Li, Liang Z
2017-01-18  4:56     ` Li, Liang Z
2017-01-18  4:56       ` [Qemu-devel] " Li, Liang Z
2017-01-18  4:56       ` Li, Liang Z
2017-01-18  4:56       ` Li, Liang Z
2017-01-18 15:30       ` Michael S. Tsirkin
2017-01-18 15:30         ` [Qemu-devel] " Michael S. Tsirkin
2017-01-18 15:30         ` Michael S. Tsirkin
2017-01-18 15:30         ` Michael S. Tsirkin
2017-01-19  1:44         ` Li, Liang Z
2017-01-19  1:44           ` [Qemu-devel] " Li, Liang Z
2017-01-19  1:44           ` Li, Liang Z
2017-01-19  1:44           ` Li, Liang Z
2017-01-20 16:34           ` Michael S. Tsirkin
2017-01-20 16:34             ` [Qemu-devel] " Michael S. Tsirkin
2017-01-20 16:34             ` Michael S. Tsirkin
2017-01-20 16:34           ` Michael S. Tsirkin
2017-01-17 19:15   ` Michael S. Tsirkin
2017-01-20 11:48   ` Dr. David Alan Gilbert
2017-01-20 11:48     ` [Qemu-devel] " Dr. David Alan Gilbert
2017-01-20 11:48     ` Dr. David Alan Gilbert
2017-02-04  4:35     ` Li, Liang Z
2017-02-04  4:35       ` [Qemu-devel] " Li, Liang Z
2017-02-04  4:35       ` Li, Liang Z
2017-02-04  4:35       ` Li, Liang Z
2017-01-20 11:48   ` Dr. David Alan Gilbert
2016-12-21  6:52 ` Liang Li
2016-12-21  6:52 ` [PATCH v6 kernel 4/5] virtio-balloon: define flags and head for host request vq Liang Li
2016-12-21  6:52   ` [Qemu-devel] " Liang Li
2016-12-21  6:52   ` Liang Li
2016-12-21  6:52 ` Liang Li
2016-12-21  6:52 ` [PATCH v6 kernel 5/5] virtio-balloon: tell host vm's unused page info Liang Li
2016-12-21  6:52   ` [Qemu-devel] " Liang Li
2016-12-21  6:52   ` Liang Li
2016-12-21  6:52 ` Liang Li
2017-01-10  6:43 ` [PATCH v6 kernel 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration Li, Liang Z
2017-01-10  6:43   ` [Qemu-devel] " Li, Liang Z
2017-01-10  6:43   ` Li, Liang Z
2017-01-10  6:43   ` Li, Liang Z
2017-01-18 10:09 ` David Hildenbrand [this message]
2017-01-18 10:09   ` [Qemu-devel] " David Hildenbrand
2017-01-18 10:09   ` David Hildenbrand
2017-01-18 10:09   ` David Hildenbrand
2017-01-18 13:29   ` Li, Liang Z
2017-01-18 13:29     ` [Qemu-devel] " Li, Liang Z
2017-01-18 13:29     ` Li, Liang Z
2017-01-18 13:29     ` Li, Liang Z
2017-01-18 13:29   ` Li, Liang Z
2017-01-18 15:38   ` Michael S. Tsirkin
2017-01-18 15:38   ` Michael S. Tsirkin
2017-01-18 15:38     ` [Qemu-devel] " Michael S. Tsirkin
2017-01-18 15:38     ` Michael S. Tsirkin
2017-01-19 17:24     ` David Hildenbrand
2017-01-19 17:24     ` David Hildenbrand
2017-01-19 17:24       ` [Qemu-devel] " David Hildenbrand
2017-01-19 17:24       ` David Hildenbrand

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=2a32f616-25a8-ba5a-f74c-d619fc8ab333@redhat.com \
    --to=david@redhat.com \
    --cc=aarcange@redhat.com \
    --cc=amit.shah@redhat.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=dave.hansen@intel.com \
    --cc=dgilbert@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=liang.z.li@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=virtualization@lists.linux-foundation.org \
    /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.