From owner-freebsd-xen@FreeBSD.ORG Fri Jun 20 09:36:10 2014 Return-Path: Delivered-To: freebsd-xen@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 B95DAEA6; Fri, 20 Jun 2014 09:36:10 +0000 (UTC) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Cybertrust Public SureServer SV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A41112989; Fri, 20 Jun 2014 09:36:09 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.01,513,1400025600"; d="scan'208";a="145670617" Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net) ([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP; 20 Jun 2014 09:36:00 +0000 Received: from [127.0.0.1] (10.80.16.47) by smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id 14.3.181.6; Fri, 20 Jun 2014 05:35:59 -0400 Message-ID: <53A40079.9000804@citrix.com> Date: Fri, 20 Jun 2014 11:35:53 +0200 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= 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: , "freebsd-xen@freebsd.org" , Subject: FreeBSD and memory balloon drivers X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-DLP: MIA1 X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 09:36:10 -0000 Hello, I've been looking into the Xen balloon driver, because I've experienced problems when ballooning memory down which AFAICT are also present in the VirtIO balloon driver. The problem I've experienced is that when ballooning memory down, we basically allocate a bunch of memory as WIRED, to make sure nobody tries to swap it do disk, since it will crash the kernel because the memory is not populated. Due to this massive amount of memory allocated as WIRED, user-space programs that try to use mlock will fail because we hit the limit in vm.max_wired. I'm not sure what's the best way to deal with this limitation, should vm.max_wired be changed from the balloon drivers when ballooning down/up? Is there anyway to remove the pages ballooned down from the memory accounting of wired pages? Thanks, Roger.