Re: [Qemu-devel] [RFC PATCH RDMA support v4: 03/10] more verbose documentation of the RDMA transport

["Michael R. Hines" <mrhines@linux.vnet.ibm.com>]

This is actual a much bigger problem that I thought, not just for RDMA:

Currently the *sender* side is does not support overcommit
during a regular TCP migration.......I assume because the
migration_bitmap does not know which memory is mapped or
unmapped by the host kernel.

Is this a known issue?

- Michael

On 03/19/2013 04:19 AM, Michael S. Tsirkin wrote:
> On Mon, Mar 18, 2013 at 07:23:53PM -0400, Michael R. Hines wrote:
>> On 03/18/2013 05:26 PM, Michael S. Tsirkin wrote:
>>> Probably but I haven't mentioned ballooning at all.
>>>
>>> memory overcommit != ballooning
>> Sure, then setting ballooning aside for the moment,
>> then let's just consider regular (unused) virtual memory.
>>
>> In this case, what's wrong with the destination mapping
>> and pinning all the memory if it is not being ballooned?
>>
>> If the guest touches all the memory during normal operation
>> before migration begins (which would be the common case),
>> then overcommit is irrelevant, no?
> We have ways (e.g. cgroups) to limit what a VM can do. If it tries to
> use more RAM than we let it, it will swap, still making progress, just
> slower.  OTOH it looks like pinning more memory than allowed by the
> cgroups limit will just get stuck forever (probably a bug,
> should fail instead? but does not help your protocol
> which needs it all pinned at all times).
>
> There are also per-task resource limits. If you exceed this
> registration will fail, so not good either.
>
> I just don't see why do registration by chunks
> on source but not on destination.
>