From owner-freebsd-current@FreeBSD.ORG Sun Aug 11 16:59:41 2013 Return-Path: Delivered-To: freebsd-current@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 ESMTP id A4EAC7EC; Sun, 11 Aug 2013 16:59:41 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-bk0-x22a.google.com (mail-bk0-x22a.google.com [IPv6:2a00:1450:4008:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A8ED22D11; Sun, 11 Aug 2013 16:59:40 +0000 (UTC) Received: by mail-bk0-f42.google.com with SMTP id my10so1598927bkb.15 for ; Sun, 11 Aug 2013 09:59:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3F6QbHwc3cPURcnGFI3enNFgk3kCp/WowV7rsMqWTHM=; b=YZSFT4+Qw2YXa9dX8m/1Sffilfu4cJvFwBhJwSqOi+uSxMSP6JLcFZ1QdN0R1kre3+ TZBLl/AJfsVXVqKyp7U+OGBvoesc53yWtpfDDuLfFfU+eyqZkgIwOvxNCHIhHSzTHnyW LQOu7KPwZcFbWfuxSS8SgkqOEXSEYt8JtBi7OF09ZC/c0zAYET+ea24Z4h8Os5ZUPSYo xQvQ0OnYYOdYb6b9tK89PI3qaF3ZOHCph+xIpzEVXPZeJSpeNVxE3Qvx2BBYBu5B31Iy sOf1RqKOw4GMA2sDNmbndzZ82vIg0e4nkk+RD+I3UU+t6DwLodx24nga+o+3Iupkim8M MfoQ== X-Received: by 10.205.25.69 with SMTP id rh5mr3141127bkb.122.1376240378710; Sun, 11 Aug 2013 09:59:38 -0700 (PDT) Received: from [192.168.1.4] (adde229.neoplus.adsl.tpnet.pl. [79.184.56.229]) by mx.google.com with ESMTPSA id ct12sm4786445bkb.12.2013.08.11.09.59.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 11 Aug 2013 09:59:38 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Fix for sys_munlock(2) with racct From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: Date: Sun, 11 Aug 2013 18:59:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130720112218.GD13628@caravan.chchile.org> <115EDC04-4B95-4FB5-9092-515188D8ADA7@rice.edu> <20130721215038.GE13628@caravan.chchile.org> To: Alan Cox X-Mailer: Apple Mail (2.1508) Cc: Jeremie Le Hen , Alan Cox , freebsd-current@FreeBSD.org, Konstantin Belousov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 16:59:41 -0000 Wiadomo=B6=E6 napisana przez Alan Cox w dniu 30 lip 2013, = o godz. 19:40: > On Jul 21, 2013, at 2:50 PM, Jeremie Le Hen wrote: >>=20 >>> Also, a wired mapping can be destroyed by calling munmap(2) without >>> first calling munlock(2), in which case, RACCT_MEMLOCK will be >>> incorrect. >>=20 >> So I think the right way to tackle this is to handle racct in the vm >> layer rather than at the syscall layer. >>=20 >=20 > The VM system already maintains counters equivalent to RACCT_VMEM and = RACCT_MEMLOCK. They are "map->size" and "pmap_wired_count(map->pmap)". = Instead of maintaining duplicate counters, could the resource accounting = framework be extended to support callbacks to obtain a value when it's = actually needed? That would be rather hard. The way this works is that raccts are = hierarchical, and every time resource allocation is done, its respective counter needs to be = propagated all the way up. If it hits a limit somewhere, the racct function returns error = meaning the resource allocation was denied. In other words, racct wants to know when the = counter changes.