VM overcommit in 2.6.9-cm46 (was Re: [BProc] Valgrind and BProc (again))

[Julian S. <ju...@va...>]

> Although I agree that linking valgrind against bproc would be nasty, I
> still like the idea of stopping valgrind at a convenient moment
> though.  [...]

I've been playing with doing bproc_move at the "right" (least-worst)
time from within Valgrind.  With a bit of fd-restoring-uglyness and
preloading various .so's onto the slaves, I can get V to migrate off
the master and stay alive.  At least -- it works when V is running
in no-instrumentation mode (--tool=none).

When you try to migrate running a useful tool (memcheck) the 
migration call instantly fails.  I am doing

  ret = VG_(do_syscall3)(__NR_bproc, BPROC_SYS_MOVE, node, (UWord)&req);

(having copied relevant stuff from clients/bproc.c and {sys,kernel}/bproc.h)

So my question.  For historical reasons Memcheck allocates all required
"shadow" address space at the start, about 1.5G, with a huge mmap
of /dev/zero.  It then mprotects bits of this incrementally to bring
it into use as needed.  Most of the mapping is never used.

This only works because by default the kernel does VM overcommitting.
On some systems (Red Hat 8) this scheme fails if there isn't 1.5G of
swap to back it.

So I was wondering how your cm46 slave kernels will behave.  At the
point vmadump gets its hands on the process image this huge mapping
will have been established.  My test slave has 128M of memory and
obviously no swap.  Should migration succeed under these circumstances?

The syscall fails with EINVAL.  This I thought strange in that if 
the slave has insufficient memory surely you would return ENOMEM ?

I spent some time reading kernel/move.c -- process2move() and 
send_process(), but couldn't deduce whether or not ENOMEM would 
return in case where the slave had insufficient memory.

Really this is 2 questions:

* How does vmadump and/or 2.6.9-cm46 behave when migrating overcommitted
  space?  (the space is a map of /dev/zero with PROT_NONE).

* If a migration should fail due to lack of memory, what does sys_bproc
  return?

[[Note: I'm just trying to understand what's happening.  Not saying
  there's any problem with BProc.  We know that our big-bang allocation
  scheme is braindead and needs fixing.]]

Thanks,

J