Re: [PATCH v2 6/8] kvm tools: Add rwlock wrapper

Sasha Levin
2011-05-30T12:23:37Z

On Mon, 2011-05-30 at 14:20 +0200, Ingo Molnar wrote:
> * Sasha Levin <levinsasha928@gmail.com> wrote:
>
> > On Mon, 2011-05-30 at 14:55 +0300, Pekka Enberg wrote:
> > > On Mon, May 30, 2011 at 2:49 PM, Ingo Molnar <mingo@elte.hu> wrote:
> > > > [*] Would be nice if tools/kvm/ had a debug option to simulate 'lots
> > > > of RAM' as well somehow - perhaps by not pre-initializing it and
> > > > somehow catching all-zeroes pages and keeping them all zeroes and
> > > > shared? It would obviously OOM after some time but would allow me
> > > > to at least boot a fair deal of userspace. The motivation is that
> > > > i have recently received a 1 TB RAM bugreport. 1 TB of RAM mapped
> > > > with 2MB mappings should still be able to boot to shell on a 32
> > > > GB RAM testbox of mine, and survive there for some time. We could
> > > > even do some kernel modifications to make this kind of simulation
> > > > easier.
> > >
> > > Doesn't our mmap() overcommit work for you? IIRC, Sasha booted guests
> > > with huge amounts of overcommitted RAM.
> >
> > It should. I can (easily) boot 64GB guest on my 4GB laptop. We fail at
> > >64GB due to an issue with our mappings (I haven't investigated it yet)
> > - not due to running out of memory.
>
> Oh, that's neat. Btw., i think there should be an option to actually
> *force* blatant overcommit: if i typo the option i'd like the tool to
> tell me that i'm probably stupid and refuse to run with that (and
> suggest the force-overcommit option), instead of trying to swap itelf
> to death!

How much is a 'blatant' overcommit? KVM easily handles x32 of host RAM.

> How does this work in practice - i thought we memset() all of RAM
> during guest kernel bootup. That might have changed with the memblock
> allocator ... So the guest kernel does not touch all of that 64 GB of
> RAM, so your box wont OOM straight away?

We simply mmap() with MAP_NORESERVE.

--

Sasha.