Re: [PATCHv2] rdma: add a new IB_ACCESS_GIFT flag

From: Michael R. Hines
Date: Wed Apr 10 2013 - 00:32:43 EST


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'm reffering to dynamic server page registration.

Of course it does not eliminate pinning - but it does mitigate the foot print of the VM as a feature that was requested.

I have implemented it and documented it.

- Michael

On 04/09/2013 03:03 PM, Michael S. Tsirkin wrote:
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
measureable gain from the patch.


On Fri, Apr 05, 2013 at 05:32:30PM -0400, Michael R. Hines wrote:
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
<mrhines@xxxxxxxxxxxxxxxxxx> 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 GIFT flag allows the
adapter to transmit stale memory information, it does not have anything to
do with cgroups specifically).
The point of the GIFT patch is to avoid triggering copy-on-write so
that memory doesn't blow up during migration. If that doesn't work
then there's no point to the patch.

- R.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/