From owner-svn-src-head@FreeBSD.ORG Wed Jun 25 17:43:09 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E98E874; Wed, 25 Jun 2014 17:43:09 +0000 (UTC) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2513A21E7; Wed, 25 Jun 2014 17:43:07 +0000 (UTC) Received: by mail-we0-f174.google.com with SMTP id u57so2473375wes.19 for ; Wed, 25 Jun 2014 10:43:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=iCFGJhmL1cEDIX5hfkyNrVKQgEdfrfNqbq8vVcVR4jw=; b=xy20UVgGG4jVL6qUuBKp+QFvUPTZtO9WRa311HU3YAAKqr+TPDUzfo4/C9jJPuy6XA 5x1PV3zlTEE+ShdjxxJh7HsZwc0H3L45PsNP1QDbGyc4HeqiZrm2MPNWHo6jdqL/Ihu1 l2BRriMN7RUQUmS5/YD4EiSXaai5ER/XbYWKmo+Vt8Z/26Oe4fByv7WEf6xDqPsyEtIR bVlYEtnIZQtj/IR/Pt3pl7cdwxoaIJKdwBW7v7zuGOFw1VS0bfrjzq0OO967XNUxp7E6 X41TP6WlSOjYlddvKeTATurzBWPt9de92xBeoY+agV6zpPbp9II9/LiHgyGQrtz1Vp8/ VJZA== X-Received: by 10.194.178.7 with SMTP id cu7mr11319395wjc.54.1403718186441; Wed, 25 Jun 2014 10:43:06 -0700 (PDT) Received: from [172.16.1.30] (39.Red-2-136-52.dynamicIP.rima-tde.net. [2.136.52.39]) by mx.google.com with ESMTPSA id am10sm8774308wjc.45.2014.06.25.10.43.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Jun 2014 10:43:05 -0700 (PDT) Sender: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Message-ID: <53AB0A23.6020605@FreeBSD.org> Date: Wed, 25 Jun 2014 19:42:59 +0200 From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alan Cox , attilio@FreeBSD.org, Alan Cox Subject: Re: svn commit: r267858 - in head/sys/dev: virtio/balloon xen/balloon References: <201406250951.s5P9p8YR017159@svn.freebsd.org> <53AACEAB.3090702@FreeBSD.org> <53AAFD12.5030308@rice.edu> In-Reply-To: <53AAFD12.5030308@rice.edu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , "src-committers@freebsd.org" X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 17:43:09 -0000 On 25/06/14 18:47, Alan Cox wrote: > On 06/25/2014 08:29, Roger Pau Monné wrote: >> On 25/06/14 13:58, Attilio Rao wrote: >>> On Wed, Jun 25, 2014 at 11:51 AM, Roger Pau Monné wrote: >>>> Author: royger >>>> Date: Wed Jun 25 09:51:08 2014 >>>> New Revision: 267858 >>>> URL: http://svnweb.freebsd.org/changeset/base/267858 >>>> >>>> Log: >>>> xen/virtio: fix balloon drivers to not mark pages as WIRED >>>> >>>> Prevent the Xen and VirtIO balloon drivers from marking pages as >>>> wired. This prevents them from increasing the system wired page count, >>>> which can lead to mlock failing because of hitting the limit in >>>> vm.max_wired. >>> This change is conceptually wrong. >>> The pages balloon is allocating are unmanaged and they should be wired >>> by definition. Alan and I are considering enforcing this (mandatory >>> wired pages for unmanaged pages allocation) directly in the KPI. >>> This in practice just seem an artifact to deal with scarce wired >>> memory limit. I suggest that for the XEN case this limit gets bumped >>> rather relying on similar type of hacks. >> IMHO, marking them as wired seems wrong too, those pages are not wired, >> they are simply not there any more. This was discussed in: >> >> http://lists.freebsd.org/pipermail/freebsd-virtualization/2014-June/002643.html >> >> If there's consensus I will revert the change, but I would say that >> increasing vm.max_wired for VMs is also a gross hack. > > We wouldn't be changing it just for VMs. Our current definition of > vm_max_wired dates back to r5455, or in human years 1995. If the ZFS > ARC has taught us anything, we, or really the page daemon, can cope with > having more than 1/3 of a machine's pages wired. :-) > > I have a couple questions for you. Exactly how much memory will Xen try > to steal from a domain via ballooning? Clearly the domain can fail to > respond to the balloon request and Xen has to cope with that. Can the > domain also explicitly say, "No, I'm not giving you any pages." Xen itself won't try to steal any memory from a VM, this is AFAIK initiated by the host admin (or maybe some high-level orchestration toolstack), which requests the domain to balloon down. The domain is never forced to balloon down, is just a petition that the VM usually tries to satisfy as much as it can (or completely ignore it). As said before, I'm not sure what high-level toolstacks will do, maybe some of them will just kill the domain if it doesn't balloon down as expected, but I would be quite surprised if that's the case. For example I've tried ballooning down a FreeBSD VM from 2GB to 256MB, and only got it to ~300MB, but that's perfectly fine IMHO. Roger.