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
