qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH RDMA support v4: 03/10] more verbose documen


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [RFC PATCH RDMA support v4: 03/10] more verbose documentation of the RDMA transport
Date: Tue, 19 Mar 2013 17:36:58 +0200

On Tue, Mar 19, 2013 at 11:32:49AM -0400, Michael R. Hines wrote:
> On 03/19/2013 11:16 AM, Michael S. Tsirkin wrote:
> >On Tue, Mar 19, 2013 at 11:08:24AM -0400, Michael R. Hines wrote:
> >>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
> >I don't really understand what you are saying here.
> >Do you see some bug with migration where we might use
> >more memory than allowed by cgroups?
> >
> 
> Yes: cgroups does not coordinate with the list of pages
> that have "not yet been mapped" or touched by the
> virtual machine, right?
> 
> I may be missing something here from what I read in
> the code, but even if I set a cgroups limit on memory,
> QEMU will still attempt to access that memory if the
> migration_bitmap tells it to, as far as I can tell.
> 
> Is this an accurate observation?

Yes but this simply means QEMU will hit swap.

> A simple solution would be to just have QEMU consult with /dev/pagemap, no?
> 
> - Michael



reply via email to

[Prev in Thread] Current Thread [Next in Thread]