On Sun, Apr 14, 2013 at 09:06:36PM -0400, Michael R. Hines wrote:
On 04/14/2013 05:10 PM, Michael S. Tsirkin wrote:
On Sun, Apr 14, 2013 at 03:06:11PM -0400, Michael R. Hines wrote:
On 04/14/2013 02:30 PM, Michael S. Tsirkin wrote:
On Sun, Apr 14, 2013 at 12:40:10PM -0400, Michael R. Hines
On Sun, Apr 14, 2013 at 09:10:36PM -0400, Michael R. Hines wrote:
On 04/14/2013 05:16 PM, Michael S. Tsirkin wrote:
On Sun, Apr 14, 2013 at 03:43:28PM -0400, Michael R. Hines wrote:
On 04/14/2013 02:51 PM, Michael S. Tsirkin wrote:
On Sun, Apr 14, 2013 at 10:31:20AM -0400, Michael R. Hines
Il 14/04/2013 21:06, Michael R. Hines ha scritto:
3. Migration with RDMA support is experimental and unsupported.
In particular, please do not expect it to work across qemu versions,
and do not expect the management interface to be stable.
The only correct statement here is
Il 15/04/2013 03:06, Michael R. Hines ha scritto:
Next, decide if you want dynamic page registration on the server-side.
For example, if you have an 8GB RAM virtual machine, but only 1GB
is in active use, then disabling this feature will cause all 8GB to
be pinned and resident in memory. This
Il 15/04/2013 03:10, Michael R. Hines ha scritto:
And when someone writes them one day, we'll have to carry the old code
around for interoperability as well. Not pretty. To avoid that, you
need to explicitly say in the documenation that it's experimental and
unsupported.
That's what
On 04/15/2013 04:28 AM, Paolo Bonzini wrote:
Il 15/04/2013 03:06, Michael R. Hines ha scritto:
Next, decide if you want dynamic page registration on the server-side.
For example, if you have an 8GB RAM virtual machine, but only 1GB
is in active use, then disabling this feature will cause all
On 04/15/2013 02:00 AM, Michael S. Tsirkin wrote:
On Sun, Apr 14, 2013 at 09:06:36PM -0400, Michael R. Hines wrote:
On 04/14/2013 05:10 PM, Michael S. Tsirkin wrote:
On Sun, Apr 14, 2013 at 03:06:11PM -0400, Michael R. Hines wrote:
On 04/14/2013 02:30 PM, Michael S. Tsirkin wrote:
On Sun,
On 04/15/2013 04:34 AM, Paolo Bonzini wrote:
Il 15/04/2013 03:10, Michael R. Hines ha scritto:
And when someone writes them one day, we'll have to carry the old code
around for interoperability as well. Not pretty. To avoid that, you
need to explicitly say in the documenation that it's
Il 15/04/2013 15:24, Michael R. Hines ha scritto:
Now, in this example, let's say the migration starts up and the hypervisor
has run out of physical memory and starts swapping during the migration.
(also for the sake of argument).
The next thing that would immediately happen is the
next IB
On 04/15/2013 09:30 AM, Paolo Bonzini wrote:
Il 15/04/2013 15:24, Michael R. Hines ha scritto:
Now, in this example, let's say the migration starts up and the hypervisor
has run out of physical memory and starts swapping during the migration.
(also for the sake of argument).
The next thing
On Mon, Apr 15, 2013 at 09:07:01AM -0400, Michael R. Hines wrote:
On 04/15/2013 02:00 AM, Michael S. Tsirkin wrote:
On Sun, Apr 14, 2013 at 09:06:36PM -0400, Michael R. Hines wrote:
On 04/14/2013 05:10 PM, Michael S. Tsirkin wrote:
On Sun, Apr 14, 2013 at 03:06:11PM -0400, Michael R. Hines
On Fri, Apr 12, 2013 at 09:47:08AM -0400, Michael R. Hines wrote:
Second, as I've explained, I strongly, strongly disagree with unregistering
memory for all of the aforementioned reasons - workloads do not
operate in such a manner that they can tolerate memory to be
pulled out from underneath
On Fri, Apr 12, 2013 at 04:43:54PM +0200, Paolo Bonzini wrote:
Il 12/04/2013 13:25, Michael S. Tsirkin ha scritto:
On Fri, Apr 12, 2013 at 12:53:11PM +0200, Paolo Bonzini wrote:
Il 12/04/2013 12:48, Michael S. Tsirkin ha scritto:
1. You have two protocols already and this does not make
Il 14/04/2013 13:59, Michael S. Tsirkin ha scritto:
I agree assuming guest has lots of zero pages won't work, but I think
you are overstating the importance of overcommit. Let's mark the damn
thing as experimental, and stop making perfect the enemy of good.
It looks like we have to
On 04/14/2013 07:59 AM, Michael S. Tsirkin wrote:
On Fri, Apr 12, 2013 at 04:43:54PM +0200, Paolo Bonzini wrote:
Il 12/04/2013 13:25, Michael S. Tsirkin ha scritto:
On Fri, Apr 12, 2013 at 12:53:11PM +0200, Paolo Bonzini wrote:
Il 12/04/2013 12:48, Michael S. Tsirkin ha scritto:
1. You have
On 04/14/2013 04:28 AM, Michael S. Tsirkin wrote:
On Fri, Apr 12, 2013 at 09:47:08AM -0400, Michael R. Hines wrote:
Second, as I've explained, I strongly, strongly disagree with unregistering
memory for all of the aforementioned reasons - workloads do not
operate in such a manner that they can
On 04/14/2013 10:09 AM, Paolo Bonzini wrote:
Il 14/04/2013 13:59, Michael S. Tsirkin ha scritto:
I agree assuming guest has lots of zero pages won't work, but I think
you are overstating the importance of overcommit. Let's mark the damn
thing as experimental, and stop making perfect the enemy
On Sun, Apr 14, 2013 at 10:27:24AM -0400, Michael R. Hines wrote:
On 04/14/2013 07:59 AM, Michael S. Tsirkin wrote:
On Fri, Apr 12, 2013 at 04:43:54PM +0200, Paolo Bonzini wrote:
Il 12/04/2013 13:25, Michael S. Tsirkin ha scritto:
On Fri, Apr 12, 2013 at 12:53:11PM +0200, Paolo Bonzini wrote:
On 04/14/2013 12:03 PM, Michael S. Tsirkin wrote:
On Sun, Apr 14, 2013 at 10:27:24AM -0400, Michael R. Hines wrote:
On 04/14/2013 07:59 AM, Michael S. Tsirkin wrote:
On Fri, Apr 12, 2013 at 04:43:54PM +0200, Paolo Bonzini wrote:
Il 12/04/2013 13:25, Michael S. Tsirkin ha scritto:
On Fri, Apr
On 04/14/2013 12:03 PM, Michael S. Tsirkin wrote:
On Sun, Apr 14, 2013 at 10:27:24AM -0400, Michael R. Hines wrote:
On 04/14/2013 07:59 AM, Michael S. Tsirkin wrote:
On Fri, Apr 12, 2013 at 04:43:54PM +0200, Paolo Bonzini wrote:
Il 12/04/2013 13:25, Michael S. Tsirkin ha scritto:
On Fri, Apr
On Sun, Apr 14, 2013 at 12:40:10PM -0400, Michael R. Hines wrote:
On 04/14/2013 12:03 PM, Michael S. Tsirkin wrote:
On Sun, Apr 14, 2013 at 10:27:24AM -0400, Michael R. Hines wrote:
On 04/14/2013 07:59 AM, Michael S. Tsirkin wrote:
On Fri, Apr 12, 2013 at 04:43:54PM +0200, Paolo Bonzini wrote:
On Sun, Apr 14, 2013 at 10:31:20AM -0400, Michael R. Hines wrote:
On 04/14/2013 04:28 AM, Michael S. Tsirkin wrote:
On Fri, Apr 12, 2013 at 09:47:08AM -0400, Michael R. Hines wrote:
Second, as I've explained, I strongly, strongly disagree with unregistering
memory for all of the aforementioned
On 04/14/2013 02:30 PM, Michael S. Tsirkin wrote:
On Sun, Apr 14, 2013 at 12:40:10PM -0400, Michael R. Hines wrote:
On 04/14/2013 12:03 PM, Michael S. Tsirkin wrote:
On Sun, Apr 14, 2013 at 10:27:24AM -0400, Michael R. Hines wrote:
On 04/14/2013 07:59 AM, Michael S. Tsirkin wrote:
On Fri,
On 04/14/2013 02:51 PM, Michael S. Tsirkin wrote:
On Sun, Apr 14, 2013 at 10:31:20AM -0400, Michael R. Hines wrote:
On 04/14/2013 04:28 AM, Michael S. Tsirkin wrote:
On Fri, Apr 12, 2013 at 09:47:08AM -0400, Michael R. Hines wrote:
Second, as I've explained, I strongly, strongly disagree with
On Sun, Apr 14, 2013 at 03:06:11PM -0400, Michael R. Hines wrote:
On 04/14/2013 02:30 PM, Michael S. Tsirkin wrote:
On Sun, Apr 14, 2013 at 12:40:10PM -0400, Michael R. Hines wrote:
On 04/14/2013 12:03 PM, Michael S. Tsirkin wrote:
On Sun, Apr 14, 2013 at 10:27:24AM -0400, Michael R. Hines
On Sun, Apr 14, 2013 at 03:43:28PM -0400, Michael R. Hines wrote:
On 04/14/2013 02:51 PM, Michael S. Tsirkin wrote:
On Sun, Apr 14, 2013 at 10:31:20AM -0400, Michael R. Hines wrote:
On 04/14/2013 04:28 AM, Michael S. Tsirkin wrote:
On Fri, Apr 12, 2013 at 09:47:08AM -0400, Michael R. Hines
On 04/14/2013 05:10 PM, Michael S. Tsirkin wrote:
On Sun, Apr 14, 2013 at 03:06:11PM -0400, Michael R. Hines wrote:
On 04/14/2013 02:30 PM, Michael S. Tsirkin wrote:
On Sun, Apr 14, 2013 at 12:40:10PM -0400, Michael R. Hines wrote:
On 04/14/2013 12:03 PM, Michael S. Tsirkin wrote:
On Sun,
On 04/14/2013 05:16 PM, Michael S. Tsirkin wrote:
On Sun, Apr 14, 2013 at 03:43:28PM -0400, Michael R. Hines wrote:
On 04/14/2013 02:51 PM, Michael S. Tsirkin wrote:
On Sun, Apr 14, 2013 at 10:31:20AM -0400, Michael R. Hines wrote:
On 04/14/2013 04:28 AM, Michael S. Tsirkin wrote:
On Fri,
On Thu, Apr 11, 2013 at 04:33:03PM -0400, Michael R. Hines wrote:
On 04/11/2013 03:15 PM, Michael S. Tsirkin wrote:
On Thu, Apr 11, 2013 at 01:49:34PM -0400, Michael R. Hines wrote:
On 04/11/2013 10:56 AM, Michael S. Tsirkin wrote:
On Thu, Apr 11, 2013 at 04:50:21PM +0200, Paolo Bonzini wrote:
Il 12/04/2013 12:48, Michael S. Tsirkin ha scritto:
1. You have two protocols already and this does not make sense in
version 1 of the patch.
It makes sense if we consider it experimental (add x- in front of
transport and capability) and would like people to play with it.
Paolo
On Fri, Apr 12, 2013 at 12:53:11PM +0200, Paolo Bonzini wrote:
Il 12/04/2013 12:48, Michael S. Tsirkin ha scritto:
1. You have two protocols already and this does not make sense in
version 1 of the patch.
It makes sense if we consider it experimental (add x- in front of
transport and
On 04/12/2013 06:48 AM, Michael S. Tsirkin wrote:
On Thu, Apr 11, 2013 at 04:33:03PM -0400, Michael R. Hines wrote:
On 04/11/2013 03:15 PM, Michael S. Tsirkin wrote:
On Thu, Apr 11, 2013 at 01:49:34PM -0400, Michael R. Hines wrote:
On 04/11/2013 10:56 AM, Michael S. Tsirkin wrote:
On Thu,
Il 12/04/2013 13:25, Michael S. Tsirkin ha scritto:
On Fri, Apr 12, 2013 at 12:53:11PM +0200, Paolo Bonzini wrote:
Il 12/04/2013 12:48, Michael S. Tsirkin ha scritto:
1. You have two protocols already and this does not make sense in
version 1 of the patch.
It makes sense if we consider it
On Wed, Apr 10, 2013 at 04:05:34PM -0400, Michael R. Hines wrote:
On 04/10/2013 01:41 PM, Michael S. Tsirkin wrote:
Thanks.
However, IMHO restricting the policy to only used chunk-based is really
not an acceptable choice:
Here's the reason: Using my 10gbs RDMA hardware, throughput takes
On 04/11/2013 03:19 AM, Michael S. Tsirkin wrote:
On Wed, Apr 10, 2013 at 04:05:34PM -0400, Michael R. Hines wrote:
Maybe we should just say RDMA is incompatible with memory overcommit
and be done with it then. But see below.
I would like to propose a compromise:
How about we *keep* the
On Thu, Apr 11, 2013 at 09:12:17AM -0400, Michael R. Hines wrote:
On 04/11/2013 03:19 AM, Michael S. Tsirkin wrote:
On Wed, Apr 10, 2013 at 04:05:34PM -0400, Michael R. Hines wrote:
Maybe we should just say RDMA is incompatible with memory
overcommit and be done with it then. But see below.
I
On 04/11/2013 09:48 AM, Michael S. Tsirkin wrote:
On Thu, Apr 11, 2013 at 09:12:17AM -0400, Michael R. Hines wrote:
On 04/11/2013 03:19 AM, Michael S. Tsirkin wrote:
On Wed, Apr 10, 2013 at 04:05:34PM -0400, Michael R. Hines wrote:
Maybe we should just say RDMA is incompatible with memory
On Thu, Apr 11, 2013 at 09:58:50AM -0400, Michael R. Hines wrote:
On 04/11/2013 09:48 AM, Michael S. Tsirkin wrote:
On Thu, Apr 11, 2013 at 09:12:17AM -0400, Michael R. Hines wrote:
On 04/11/2013 03:19 AM, Michael S. Tsirkin wrote:
On Wed, Apr 10, 2013 at 04:05:34PM -0400, Michael R. Hines
Il 11/04/2013 16:37, Michael S. Tsirkin ha scritto:
pg1 - pin - req - res - rdma - done
pg2 - pin - req - res - rdma - done
pg3 - pin - req - res - rdma - done
pg4 - pin - req - res - rdma - done
pg4 - pin - req
You cannot write data in the pipeline because you do not have the
permissions to do so yet until the registrations in the pipeline have
completed and been received by the primary VM.
On 04/11/2013 10:50 AM, Paolo Bonzini wrote:
Il 11/04/2013 16:37, Michael S. Tsirkin ha scritto:
pg1 - pin -
On Thu, Apr 11, 2013 at 04:50:21PM +0200, Paolo Bonzini wrote:
Il 11/04/2013 16:37, Michael S. Tsirkin ha scritto:
pg1 - pin - req - res - rdma - done
pg2 - pin - req - res - rdma - done
pg3 - pin - req - res - rdma - done
pg4 - pin -
First of all, this whole argument should not even exist for the
following reason:
Page registrations are supposed to be *rare* - once a page is registered, it
is registered for life. There is nothing in the design that says a page must
be unregistered and I do not believe anybody is proposing
Il 11/04/2013 17:18, Michael R. Hines ha scritto:
First of all, this whole argument should not even exist for the
following reason:
Page registrations are supposed to be *rare* - once a page is
registered, it is registered for life.
Uh-oh. That changes things a lot. We do not even need
On Thu, Apr 11, 2013 at 05:33:41PM +0200, Paolo Bonzini wrote:
Il 11/04/2013 17:18, Michael R. Hines ha scritto:
First of all, this whole argument should not even exist for the
following reason:
Page registrations are supposed to be *rare* - once a page is
registered, it is
On Thu, Apr 11, 2013 at 05:47:53PM +0200, Paolo Bonzini wrote:
Il 11/04/2013 17:46, Michael S. Tsirkin ha scritto:
Ok, let's keep it simple. The only two things we need are:
1) remove the patch to disable is_dup_page
2) rename the transport to x-rdma (just in migration.c)
On Thu, Apr 11, 2013 at 11:18:56AM -0400, Michael R. Hines wrote:
First of all,
I know it's a hard habit to break but could you
please stop stop top-posting?
this whole argument should not even exist for the
following reason:
Page registrations are supposed to be *rare* - once a page is
Il 11/04/2013 17:46, Michael S. Tsirkin ha scritto:
Ok, let's keep it simple. The only two things we need are:
1) remove the patch to disable is_dup_page
2) rename the transport to x-rdma (just in migration.c)
Both things together let us keep it safe for a release or two. Let's
On Thu, Apr 11, 2013 at 12:09:44PM -0400, Michael R. Hines wrote:
On 04/11/2013 11:44 AM, Michael S. Tsirkin wrote:
On Thu, Apr 11, 2013 at 11:18:56AM -0400, Michael R. Hines wrote:
First of all,
I know it's a hard habit to break but could you
please stop stop top-posting?
Acknowledged.
On 04/11/2013 01:04 PM, Michael S. Tsirkin wrote:
On Thu, Apr 11, 2013 at 12:09:44PM -0400, Michael R. Hines wrote:
Yes, that's correct. The agony is just delayed. The right thing to do
in a future patch would be to pin as much as possible in advance
before the bulk phase round even begins
On 04/11/2013 11:58 AM, Michael S. Tsirkin wrote:
On Thu, Apr 11, 2013 at 05:47:53PM +0200, Paolo Bonzini wrote:
Il 11/04/2013 17:46, Michael S. Tsirkin ha scritto:
Ok, let's keep it simple. The only two things we need are:
1) remove the patch to disable is_dup_page
2) rename the transport
On 04/11/2013 10:56 AM, Michael S. Tsirkin wrote:
On Thu, Apr 11, 2013 at 04:50:21PM +0200, Paolo Bonzini wrote:
Il 11/04/2013 16:37, Michael S. Tsirkin ha scritto:
pg1 - pin - req - res - rdma - done
pg2 - pin - req - res - rdma - done
pg3 - pin - req - res - rdma
On 04/11/2013 11:44 AM, Michael S. Tsirkin wrote:
On Thu, Apr 11, 2013 at 11:18:56AM -0400, Michael R. Hines wrote:
First of all,
I know it's a hard habit to break but could you
please stop stop top-posting?
this whole argument should not even exist for the
following reason:
Page
On 04/11/2013 11:44 AM, Michael S. Tsirkin wrote:
On Thu, Apr 11, 2013 at 11:18:56AM -0400, Michael R. Hines wrote:
First of all,
I know it's a hard habit to break but could you
please stop stop top-posting?
Acknowledged.
this whole argument should not even exist for the
following reason:
On Thu, Apr 11, 2013 at 01:49:34PM -0400, Michael R. Hines wrote:
On 04/11/2013 10:56 AM, Michael S. Tsirkin wrote:
On Thu, Apr 11, 2013 at 04:50:21PM +0200, Paolo Bonzini wrote:
Il 11/04/2013 16:37, Michael S. Tsirkin ha scritto:
pg1 - pin - req - res - rdma - done
pg2 - pin - req
On 04/11/2013 03:15 PM, Michael S. Tsirkin wrote:
On Thu, Apr 11, 2013 at 01:49:34PM -0400, Michael R. Hines wrote:
On 04/11/2013 10:56 AM, Michael S. Tsirkin wrote:
On Thu, Apr 11, 2013 at 04:50:21PM +0200, Paolo Bonzini wrote:
Il 11/04/2013 16:37, Michael S. Tsirkin ha scritto:
pg1 - pin
On 04/11/2013 11:33 AM, Paolo Bonzini wrote:
2) rename the transport to x-rdma (just in migration.c)
What does this mean?
Il 12/04/2013 07:10, Michael R. Hines ha scritto:
On 04/11/2013 11:33 AM, Paolo Bonzini wrote:
2) rename the transport to x-rdma (just in migration.c)
What does this mean?
Use migrate x-rdma:192.168.10.12 to migrate, to indicate it's
experimental and the protocol might change. It's just to
On 04/12/2013 01:26 AM, Paolo Bonzini wrote:
Il 12/04/2013 07:10, Michael R. Hines ha scritto:
On 04/11/2013 11:33 AM, Paolo Bonzini wrote:
2) rename the transport to x-rdma (just in migration.c)
What does this mean?
Use migrate x-rdma:192.168.10.12 to migrate, to indicate it's
experimental
Below is a great high level overview. the protocol looks correct.
A bit more detail would be helpful, as noted below.
The main thing I'd like to see changed is that there are already
two protocols here: chunk-based and non chunk based.
We'll need to use versioning and capabilities going forward
On 04/10/2013 01:27 AM, Michael S. Tsirkin wrote:
Below is a great high level overview. the protocol looks correct.
A bit more detail would be helpful, as noted below.
The main thing I'd like to see changed is that there are already
two protocols here: chunk-based and non chunk based.
We'll
On Wed, Apr 10, 2013 at 09:04:44AM -0400, Michael R. Hines wrote:
On 04/10/2013 01:27 AM, Michael S. Tsirkin wrote:
Below is a great high level overview. the protocol looks correct.
A bit more detail would be helpful, as noted below.
The main thing I'd like to see changed is that there are
On 04/10/2013 09:34 AM, Michael S. Tsirkin wrote:
On Wed, Apr 10, 2013 at 09:04:44AM -0400, Michael R. Hines wrote:
On 04/10/2013 01:27 AM, Michael S. Tsirkin wrote:
Below is a great high level overview. the protocol looks correct.
A bit more detail would be helpful, as noted below.
The main
On Wed, Apr 10, 2013 at 11:29:24AM -0400, Michael R. Hines wrote:
On 04/10/2013 09:34 AM, Michael S. Tsirkin wrote:
On Wed, Apr 10, 2013 at 09:04:44AM -0400, Michael R. Hines wrote:
On 04/10/2013 01:27 AM, Michael S. Tsirkin wrote:
Below is a great high level overview. the protocol looks
On 04/10/2013 01:41 PM, Michael S. Tsirkin wrote:
Thanks.
However, IMHO restricting the policy to only used chunk-based is really
not an acceptable choice:
Here's the reason: Using my 10gbs RDMA hardware, throughput takes a
dive from 10gbps to 6gbps.
Who cares about the throughput really?
64 matches
Mail list logo
