* Sasha Levin <levinsasha928@xxxxxxxxx> 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@xxxxxxx> 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 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? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
