On Mon, 2011-05-30 at 14:20 +0200, Ingo Molnar wrote: > * 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 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. -- 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
