From owner-svn-src-all@FreeBSD.ORG Wed Jun 25 17:18:46 2014 Return-Path: Delivered-To: svn-src-all@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 504572A7; Wed, 25 Jun 2014 17:18:46 +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 0E83F2F77; Wed, 25 Jun 2014 17:18:45 +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 s5PHGh0L024849; Wed, 25 Jun 2014 12:18:45 -0500 Received: from mh11.mail.rice.edu (mh11.mail.rice.edu [128.42.199.30]) by pp2.rice.edu with ESMTP id 1mqurs07pk-1; Wed, 25 Jun 2014 12:18:44 -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 D26BB4C01BA; Wed, 25 Jun 2014 12:18:43 -0500 (CDT) Message-ID: <53AB0473.8080709@rice.edu> Date: Wed, 25 Jun 2014 12:18:43 -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: Julian Elischer , Alfred Perlstein , attilio@FreeBSD.org, Gleb Smirnoff Subject: Re: svn commit: r267858 - in head/sys/dev: virtio/balloon xen/balloon References: <201406250951.s5P9p8YR017159@svn.freebsd.org> <20140625120932.GM28199@FreeBSD.org> <53AAE7D0.2090508@freebsd.org> <53AB02FD.20502@freebsd.org> In-Reply-To: <53AB02FD.20502@freebsd.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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=3 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-1406250177 Cc: Alan Cox , "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , "src-committers@freebsd.org" X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 17:18:46 -0000 On 06/25/2014 12:12, Julian Elischer wrote: > On 6/25/14, 11:16 PM, Alfred Perlstein wrote: >> On 6/25/14 5:41 AM, Attilio Rao wrote: >>> On Wed, Jun 25, 2014 at 2:09 PM, Gleb Smirnoff >>> wrote: >>>> On Wed, Jun 25, 2014 at 01:58:29PM +0200, Attilio Rao wrote: >>>> A> > Log: >>>> A> > xen/virtio: fix balloon drivers to not mark pages as WIRED >>>> A> > >>>> A> > Prevent the Xen and VirtIO balloon drivers from marking >>>> pages as >>>> A> > wired. This prevents them from increasing the system wired >>>> page count, >>>> A> > which can lead to mlock failing because of hitting the limit in >>>> A> > vm.max_wired. >>>> A> >>>> A> This change is conceptually wrong. >>>> A> The pages balloon is allocating are unmanaged and they should be >>>> wired >>>> A> by definition. Alan and I are considering enforcing this (mandatory >>>> A> wired pages for unmanaged pages allocation) directly in the KPI. >>>> A> This in practice just seem an artifact to deal with scarce wired >>>> A> memory limit. I suggest that for the XEN case this limit gets >>>> bumped >>>> A> rather relying on similar type of hacks. >>>> >>>> Proper limit would be to count pages wired by userland via mlock(2) >>>> and enforce limit only on those pages. Pages wired by kernel should >>>> be either unlimited or controled by a separate limit. >>> FWIW, I mostly agree with this. I think that the kernel and userland >>> limits should be split apart. But for the time being, rising the limit >>> is better. >>> >>> Attilio >>> >>> >> Can you explain? I would think that if you were designing some kind >> of embedded device you would want to know exactly how much locked >> pages there are overall, not just in userland. >> >> Meaning you would not want to overcommit and have too many locked >> pages due to kernel+user. >> >> Perhaps that needs an API as well? > > these pages are the VM equivalent of memory pages that were 'found to > be flaky and taken out of service" > I think "wired" is a bad description for those. > > > That doesn't matter. To the rest of the VM system, and, in particular, the page daemon, one category is indistinguishable from the other.