From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] QEMU support for virtio balloon driver Date: Sat, 26 Jan 2008 20:35:40 +0200 Message-ID: <479B7D7C.6080303@qumranet.com> References: <1201209786831-git-send-email-aliguori@us.ibm.com> <4799115F.8010506@us.ibm.com> <1201302492.2944.8.camel@localhost.localdomain> <479A7A5C.6030005@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, Marcelo Tosatti , Andrea Arcangeli To: Anthony Liguori Return-path: In-Reply-To: <479A7A5C.6030005-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org Anthony Liguori wrote: >>>> >>> Looks like it's not. I just hung my host system after doing a bunch >>> of ballooning with a kernel that doesn't have MM notifiers. >>> >>> I'm inclined to think that we should have a capability check for MM >>> notifiers and just not do madvise if they aren't present. I don't >>> think the ioctl approach that Marcelo took is sufficient as a >>> malicious guest could possibly hose the host. >>> >>> >> >> The ioctl to zap the shadow pages is needed in order to free memory >> fast. Without it the balloon will evacuate memory to slow for common >> mgmt application (running additional VMs). >> > > I think that assertion needs some performance numbers to back it up. > Linux will write unused pages to swap such that when it does need to > obtain memory, it can easily just reclaim pages without doing any disk > IO. > > The real advantage with using madvise() is that it doesn't use any > swap space (at least, on Linux). > Zapping the mmu is needed so the memory can actually be reclaimed in the absence of mmu notifiers. With mmu notifiers, it is unnecessary. > > The issue is the atomicity of removing some from the shadow MMU cache > and then madvise()'ing (since madvise is incapable of evicting from > the shadow MMU cache w/o MMU notifiers). The only real solution I > know of would be to also introduce an ioctl that's essentially, > MADVISE_AND_REMOVE_FROM_SHADOW_MMU ioctl(). > Or maybe stop all vcpus (in userspace) zap shadow madvise() resume all vcpus -- Any sufficiently difficult bug is indistinguishable from a feature. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/