From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36768) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QAoUR-0002dj-D7 for qemu-devel@nongnu.org; Fri, 15 Apr 2011 15:15:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QAoUQ-0001Wg-AV for qemu-devel@nongnu.org; Fri, 15 Apr 2011 15:15:35 -0400 Received: from e37.co.us.ibm.com ([32.97.110.158]:60407) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QAoUQ-0001WZ-4m for qemu-devel@nongnu.org; Fri, 15 Apr 2011 15:15:34 -0400 Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e37.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p3FJCi1J000722 for ; Fri, 15 Apr 2011 13:12:44 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p3FJFQUc082026 for ; Fri, 15 Apr 2011 13:15:27 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p3FJFQOe008197 for ; Fri, 15 Apr 2011 13:15:26 -0600 From: Dave Hansen In-Reply-To: <4DA87DBD.3030406@us.ibm.com> References: <1302878695-10256-1-git-send-email-dave@linux.vnet.ibm.com> <4DA87093.7050008@us.ibm.com> <1302885415.16562.3358.camel@nimitz> <4DA87DBD.3030406@us.ibm.com> Content-Type: text/plain; charset="ISO-8859-1" Date: Fri, 15 Apr 2011 12:15:18 -0700 Message-ID: <1302894918.16562.3880.camel@nimitz> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] set VIRTIO_BALLOON_F_MUST_TELL_HOST unconditionally List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Amit Shah , qemu-devel@nongnu.org On Fri, 2011-04-15 at 12:17 -0500, Anthony Liguori wrote: > On 04/15/2011 11:36 AM, Dave Hansen wrote: > >> Why would we do this in QEMU? This prevents the guest from doing > >> ballooning reclaim during OOM. > > What the heck is "ballooning reclaim"? Could you elaborate a bit on how > > this happens? I think I'm missing some subtlety here. > > If you're in OOM and you need memory, you can't ask the host for more > and wait for a response. You have to reclaim it immediately. Why not? The call in to the notifier chain the s390 case is synchronous. The OOM only affects one task at a time and won't proceed elsewhere while this is going on. > See the s390 balloon driver for an example of this. I could buy that in an OOM situation, but that's not what virtio-balloon is doing. > > I think 'tell host first' is the only sane way to do it. Look at the > > 'tell host second code': > > > > release_pages_by_pfn(); // let other kernel users at the pages > > tell_host(); // tell the hypervisor they're used again > > > At the point we've started using the pages again, we haven't *told* the > > host that we're using them. I think that's potentially a problem. Is > > qemu somehow cool with the guest touching pages that are supposed to be > > in the balloon and unusable? > > Yes, of course it is. All ballooning does is madvise(MADV_DONTNEED). A > guest can reclaim the memory as soon as it wants it to. That's not true on all hypervisors, but as long as it's a guarantee in qemu, I guess we're OK here. Let's hope nobody else ever starts to use virtio-balloon. Why do we even _tell_ qemu, though? The MADV_WILLNEED is nice, but far from being necessary. We could just skip the entire notification in OOM situations. -- Dave