From owner-svn-src-head@FreeBSD.ORG Wed Jun 25 14:06:55 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 202BC94B; Wed, 25 Jun 2014 14:06:55 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (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 1757E2BE6; Wed, 25 Jun 2014 14:06:53 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id r20so2586970wiv.16 for ; Wed, 25 Jun 2014 07:06:51 -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=v0qql7OJvRXkhzubpbqhCgUntaRZQ+75RS3/I8OWTTo=; b=ZKhr0z/dfh+gv10vdwUhp1ILTg5CkX0bsxQqX6epb9GXS9ok84n0Yi0hDn8r3JtOc9 0zO9v2N/Ts7R/lw67o2JTNkoE+UWn1xJQGlhDYRuhSlLQNqSSwvvBPH6dCVQ/cjrSwIo hKqTkYmp3OFWZCMKg3A0WHplKmDP5p666eDkSUV2l17WWpsHgZoZzNu5S5Tktjf/tm94 E4idw7ijv2EcSPsQ889FU9U5hPavY/Rh0cxo6EBA5YLxptIEAHesx/Hysn4CTn6Wen5/ Q5rBhvCOcp2yX9dahk2y0xVMpHEIKMekptBH/r7XMjsHQTz4KvQucdeKH/EuX91EeFbI piDA== X-Received: by 10.194.10.167 with SMTP id j7mr10378173wjb.100.1403705209794; Wed, 25 Jun 2014 07:06:49 -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 ez8sm12747071wib.12.2014.06.25.07.06.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Jun 2014 07:06:49 -0700 (PDT) Sender: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Message-ID: <53AAD775.8070302@FreeBSD.org> Date: Wed, 25 Jun 2014 16:06:45 +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: attilio@FreeBSD.org 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: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Alan Cox , "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 14:06:55 -0000 On 25/06/14 15:44, Attilio Rao wrote: > On Wed, Jun 25, 2014 at 3:29 PM, 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: > > I'm not entirely sure what do you mean with "not there anymore", so > I'm just guessing and I assume that you mean "pages are not collected > in any vm object and then they are not referenced in any pagequeue". > By extension this also matches what "unmanaged page" means. > > If the page is unmanaged it means that the pagedaemon won't see it, so > they won't be swapped out anyway. Wiring them it will enforce more > sanity checking on the page. The max_wired concern may be real, > however, please see below. What I meant by "not there" is that the physical addresses associated with the pages are no longer valid (it's a hole in the physical memory map). To me it seems conceptually wrong to account those pages as wired. Thinking from a user point of view for example, if I'm inside of a VM that has ballooned down, I will see a huge amount of memory marked as wired on the top utility, which seems wrong, those pages are simply not there anymore, and as so, they shouldn't show up in stats. It also makes it really hard to know which memory is really wired and in use by the system, as opposed to the wired memory used by the balloon driver. Roger.