From owner-svn-src-head@FreeBSD.ORG Wed Jun 25 15:30:13 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 AC869290; Wed, 25 Jun 2014 15:30:13 +0000 (UTC) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (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 5FD1224A6; Wed, 25 Jun 2014 15:30:12 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id z12so2201458wgg.13 for ; Wed, 25 Jun 2014 08:30:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=u3H2Q6wcLJ7mTCQee1gcmwL620ncRrofkcWwMH0Ui6w=; b=QL8UMiYMS+VpI4Sy8i+81oJNkU0KdHijZhWrD2G3e213NG5i9mCp6jezYwrRbpE3l9 XBxfl0Eh3q+agg2Kn2Cdy5hwgX3pxWd+cpyaAeL10M8at7C7gbVo9Mma9lRr/AHg32Mp Td9BRg+SkMz7PzJomEWoYaiMXrcWG7oO79ZP5wEEMKO/QB7jmvKGq0Sa1gu7OVFfvmuj rIlAE737nXXXAI8/VVnL7ZzcBfrSc0KANzqTmp16ZY3tlKaSTNQAii1sGy50S6T1vgZ2 BZI6wA8THy+WC45d+dJEMtzqhglUtqPBih1b0W6O8urUY5pGnBRdtO9NvrOirgf5iGLD kMcg== MIME-Version: 1.0 X-Received: by 10.194.157.68 with SMTP id wk4mr10837234wjb.42.1403710206393; Wed, 25 Jun 2014 08:30:06 -0700 (PDT) Reply-To: attilio@FreeBSD.org Sender: asmrookie@gmail.com Received: by 10.217.46.129 with HTTP; Wed, 25 Jun 2014 08:30:06 -0700 (PDT) In-Reply-To: <53AAE7D0.2090508@freebsd.org> References: <201406250951.s5P9p8YR017159@svn.freebsd.org> <20140625120932.GM28199@FreeBSD.org> <53AAE7D0.2090508@freebsd.org> Date: Wed, 25 Jun 2014 17:30:06 +0200 X-Google-Sender-Auth: lArvlZjfeDvbElFZhIf2Lsl-r90 Message-ID: Subject: Re: svn commit: r267858 - in head/sys/dev: virtio/balloon xen/balloon From: Attilio Rao To: Alfred Perlstein Content-Type: text/plain; charset=UTF-8 Cc: "src-committers@freebsd.org" , Alan Cox , "svn-src-all@freebsd.org" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Gleb Smirnoff , "svn-src-head@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 15:30:13 -0000 On Wed, Jun 25, 2014 at 5: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. Well, assuming you trace them indipendently I don't think this is going to be problematic to aggregate them, is it? As far as I understand it, right now we have RMEM_LIMIT to someway limit per-process amount of wired memory and finally max_wired as a global accounted wired memory limit. I think that the idea now is that RMEM_LIMIT is enough to correctly control all the front-end check, coming from untrusted sources (userland, non-privileged syscalls like mlock(), mmap(), etc.). Possibly that's not always the case and I think that the hypervisor can be a fair example of this. Having "more granular" accountability, means that rather than having a global limit (or, rather, along with it) we can grow a per-process limit to control kernel-allocated wired memory. > Perhaps that needs an API as well? I don't have anything in my mind yet. My initial point was more trying to get a better semantic on a paradigm that is at least dangerous. Attilio -- Peace can only be achieved by understanding - A. Einstein