From owner-svn-src-head@FreeBSD.ORG Wed Jun 25 16:47:17 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7AD97287; Wed, 25 Jun 2014 16:47:17 +0000 (UTC) Received: from pp2.rice.edu (proofpoint2.mail.rice.edu [128.42.201.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3D7DF2C57; Wed, 25 Jun 2014 16:47:16 +0000 (UTC) Received: from pps.filterd (pp2.rice.edu [127.0.0.1]) by pp2.rice.edu (8.14.5/8.14.5) with SMTP id s5PGWocY004919; Wed, 25 Jun 2014 11:47:15 -0500 Received: from mh11.mail.rice.edu (mh11.mail.rice.edu [128.42.199.30]) by pp2.rice.edu with ESMTP id 1mqurs071q-1; Wed, 25 Jun 2014 11:47:15 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh11.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh11.mail.rice.edu (Postfix) with ESMTPSA id 05B2A4C02FE; Wed, 25 Jun 2014 11:47:14 -0500 (CDT) Message-ID: <53AAFD12.5030308@rice.edu> Date: Wed, 25 Jun 2014 11:47:14 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , 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> In-Reply-To: <53AACEAB.3090702@FreeBSD.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.605690798989426 urlsuspect_oldscore=0.00569079898942585 suspectscore=4 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=1 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.605690798989426 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406250170 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 16:47:17 -0000 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."