From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sasha Levin Subject: Re: [PATCH v2 6/8] kvm tools: Add rwlock wrapper Date: Mon, 30 May 2011 15:22:59 +0300 Message-ID: <1306758180.14564.98.camel@lappy> References: <1306748796.14564.62.camel@lappy> <20110530095451.GB8461@elte.hu> <20110530201110.f3bf20b5.yoshikawa.takuya@oss.ntt.co.jp> <1306753954.14564.92.camel@lappy> <20110530202646.eff0ea28.yoshikawa.takuya@oss.ntt.co.jp> <4DE381DB.8040804@redhat.com> <20110530114949.GD22324@elte.hu> <1306756681.14564.95.camel@lappy> <20110530122027.GJ22324@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Pekka Enberg , Avi Kivity , Takuya Yoshikawa , kvm@vger.kernel.org, asias.hejun@gmail.com, gorcunov@gmail.com, prasadjoshi124@gmail.com, "Paul E. McKenney" , takuya.yoshikawa@gmail.com To: Ingo Molnar Return-path: Received: from mail-ww0-f44.google.com ([74.125.82.44]:60487 "EHLO mail-ww0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756897Ab1E3MXh (ORCPT ); Mon, 30 May 2011 08:23:37 -0400 Received: by wwa36 with SMTP id 36so3858844wwa.1 for ; Mon, 30 May 2011 05:23:36 -0700 (PDT) In-Reply-To: <20110530122027.GJ22324@elte.hu> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, 2011-05-30 at 14:20 +0200, Ingo Molnar wrote: > * Sasha Levin wrote: > > > On Mon, 2011-05-30 at 14:55 +0300, Pekka Enberg wrote: > > > On Mon, May 30, 2011 at 2:49 PM, Ingo Molnar 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.