On 04/10/2013 11:05 AM, Michael S. Tsirkin wrote:
On Wed, Apr 10, 2013 at 11:48:24AM -0400, Michael R. Hines wrote:
There's a very nice, simple client/server RDMA application on the
internet you can use to test your patch.
http://thegeekinthecorner.wordpress.com/2010/09/28/
rdma-read-and-write-
On Wed, Apr 10, 2013 at 11:48:24AM -0400, Michael R. Hines wrote:
>
> There's a very nice, simple client/server RDMA application on the
> internet you can use to test your patch.
>
> http://thegeekinthecorner.wordpress.com/2010/09/28/
> rdma-read-and-write-with-ib-verbs/
>
> This guy provides th
There's a very nice, simple client/server RDMA application on the
internet you can use to test your patch.
http://thegeekinthecorner.wordpress.com/2010/09/28/rdma-read-and-write-with-ib-verbs/
This guy provides the source code which dumps several gigabytes over RDMA
to the other side.
There's
On Wed, Apr 10, 2013 at 12:32:31AM -0400, Michael R. Hines wrote:
> On 04/09/2013 11:24 PM, Michael S. Tsirkin wrote:
> >Which mechanism do you refer to? You patches still seem to pin
> >each page in guest memory at some point, which will break all COW.
> >In particular any pagemap tricks to detect
On 04/09/2013 11:24 PM, Michael S. Tsirkin wrote:
Which mechanism do you refer to? You patches still seem to pin each
page in guest memory at some point, which will break all COW. In
particular any pagemap tricks to detect duplicates on source that I
suggested won't work.
Sorry, I mispoke. I
On Tue, Apr 09, 2013 at 09:26:59PM -0400, Michael R. Hines wrote:
> With respect, I'm going to offload testing this patch back to the author =)
> because I'm trying to address all of Paolo's other minor issues
> with the RDMA patch before we can merge.
Fair enough, this likely means it won't happ
With respect, I'm going to offload testing this patch back to the author =)
because I'm trying to address all of Paolo's other minor issues
with the RDMA patch before we can merge.
Since dynamic page registration (as you requested) is now fully
implemented, this patch is less urgent since we now
On Tue, Apr 09, 2013 at 11:34:09PM +0300, Michael S. Tsirkin wrote:
> On Fri, Apr 05, 2013 at 04:17:36PM -0400, Michael R. Hines wrote:
> > The userland part of the patch was missing (IBV_ACCESS_GIFT).
> >
> > I added flag that to /usr/include in addition to this patch and did
> > a test RDMA migr
On Fri, Apr 05, 2013 at 04:17:36PM -0400, Michael R. Hines wrote:
> The userland part of the patch was missing (IBV_ACCESS_GIFT).
>
> I added flag that to /usr/include in addition to this patch and did
> a test RDMA migrate and it seems to work without any problems.
>
> I also removed the IBV_*_W
On Fri, Apr 05, 2013 at 01:43:49PM -0700, Roland Dreier wrote:
> On Fri, Apr 5, 2013 at 1:17 PM, Michael R. Hines
> wrote:
> > I also removed the IBV_*_WRITE flags on the sender-side and activated
> > cgroups with the "memory.memsw.limit_in_bytes" activated and the migration
> > with RDMA also suc
On Fri, Apr 05, 2013 at 02:03:33PM -0700, Roland Dreier wrote:
> On Fri, Apr 5, 2013 at 1:51 PM, Michael R. Hines
> wrote:
> > Sorry, I was wrong. ignore the comments about cgroups. That's still broken.
> > (i.e. trying to register RDMA memory while using a cgroup swap limit cause
> > the process
presumably is_dup_page reads the page, so should not break COW ...
I'm not sure about the cgroups swap limit - you might have
too many non COW pages so attempting to fault them all in
makes you exceed the limit. You really should look at
what is going on in the pagemap, to see if there's
measureab
On Tue, Apr 09, 2013 at 01:56:00PM -0400, Michael R. Hines wrote:
> On 04/09/2013 12:39 PM, Michael S. Tsirkin wrote:
> >On Fri, Apr 05, 2013 at 04:54:39PM -0400, Michael R. Hines wrote:
> >>To be more specific, here's what I did:
> >>
> >>1. apply kernel module patch - re-insert module
> >>1. QEMU
On 04/09/2013 12:39 PM, Michael S. Tsirkin wrote:
On Fri, Apr 05, 2013 at 04:54:39PM -0400, Michael R. Hines wrote:
To be more specific, here's what I did:
1. apply kernel module patch - re-insert module
1. QEMU does: ibv_reg_mr(IBV_ACCESS_GIFT | IBV_ACCESS_REMOTE_READ)
2. Start the RDM
On Fri, Apr 05, 2013 at 04:54:39PM -0400, Michael R. Hines wrote:
> To be more specific, here's what I did:
>
> 1. apply kernel module patch - re-insert module
> 1. QEMU does: ibv_reg_mr(IBV_ACCESS_GIFT | IBV_ACCESS_REMOTE_READ)
> 2. Start the RDMA migration
> 3. Migration completes withou
Well, I have the "is_dup_page()" commented out...when RDMA is
activated.
Is there something else in QEMU that could be touching the page that I
don't know about?
- Michael
On 04/05/2013 05:03 PM, Roland Dreier wrote:
On Fri, Apr 5, 2013 at 1:51 PM, Michael R. Hines
wrote:
Sorry,
On Fri, Apr 5, 2013 at 1:51 PM, Michael R. Hines
wrote:
> Sorry, I was wrong. ignore the comments about cgroups. That's still broken.
> (i.e. trying to register RDMA memory while using a cgroup swap limit cause
> the process get killed).
>
> But the GIFT flag patch works (my understanding is that
To be more specific, here's what I did:
1. apply kernel module patch - re-insert module
1. QEMU does: ibv_reg_mr(IBV_ACCESS_GIFT | IBV_ACCESS_REMOTE_READ)
2. Start the RDMA migration
3. Migration completes without any errors
This test does *not* work with a cgroup swap limit, however. Th
Sorry, I was wrong. ignore the comments about cgroups. That's still
broken. (i.e. trying to register RDMA memory while using a cgroup swap
limit cause the process get killed).
But the GIFT flag patch works (my understanding is that GIFT flag allows
the adapter to transmit stale memory informat
On Fri, Apr 5, 2013 at 1:17 PM, Michael R. Hines
wrote:
> I also removed the IBV_*_WRITE flags on the sender-side and activated
> cgroups with the "memory.memsw.limit_in_bytes" activated and the migration
> with RDMA also succeeded without any problems (both with *and* without GIFT
> also worked).
The userland part of the patch was missing (IBV_ACCESS_GIFT).
I added flag that to /usr/include in addition to this patch and did a
test RDMA migrate and it seems to work without any problems.
I also removed the IBV_*_WRITE flags on the sender-side and activated
cgroups with the "memory.memsw
On Tue, Apr 02, 2013 at 08:05:21PM +0300, Michael S. Tsirkin wrote:
> On Tue, Apr 02, 2013 at 09:57:38AM -0700, Roland Dreier wrote:
> > On Tue, Apr 2, 2013 at 8:51 AM, Michael S. Tsirkin wrote:
> > >> At the moment registering an MR breaks COW. This breaks memory
> > >> overcommit for users such
I'm getting around to it, Michael, I promise =).
Just came back from vacation.
I have to re-build the ib_ucm kernel module from the original SUSE
kernel that I'm using along before I can test it..
The machines I'm using are slightly tied up with other things, so its
taking me a little ti
On Tue, Apr 02, 2013 at 09:57:38AM -0700, Roland Dreier wrote:
> On Tue, Apr 2, 2013 at 8:51 AM, Michael S. Tsirkin wrote:
> >> At the moment registering an MR breaks COW. This breaks memory
> >> overcommit for users such as KVM: we have a lot of COW pages, e.g.
> >> instances of the zero page or
On Tue, Apr 2, 2013 at 8:51 AM, Michael S. Tsirkin wrote:
>> At the moment registering an MR breaks COW. This breaks memory
>> overcommit for users such as KVM: we have a lot of COW pages, e.g.
>> instances of the zero page or pages shared using KSM.
>>
>> If the application does not care that ad
On Sun, Mar 24, 2013 at 05:51:53PM +0200, Michael S. Tsirkin wrote:
> At the moment registering an MR breaks COW. This breaks memory
> overcommit for users such as KVM: we have a lot of COW pages, e.g.
> instances of the zero page or pages shared using KSM.
>
> If the application does not care th
At the moment registering an MR breaks COW. This breaks memory
overcommit for users such as KVM: we have a lot of COW pages, e.g.
instances of the zero page or pages shared using KSM.
If the application does not care that adapter sees stale data (for
example, it tracks writes reregisters and rese
27 matches
Mail list logo
