Date: Sun, 11 Aug 2013 18:59:36 +0200 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= <trasz@FreeBSD.org> To: Alan Cox <alc@rice.edu> Cc: Jeremie Le Hen <jlh@FreeBSD.org>, Alan Cox <alc@FreeBSD.org>, freebsd-current@FreeBSD.org, Konstantin Belousov <kib@freebsd.org> Subject: Re: Fix for sys_munlock(2) with racct Message-ID: <F4779BEB-6F48-4A98-867C-DB40320F7865@FreeBSD.org> In-Reply-To: <EDF1EFE1-E9A9-44CF-8007-A642971572BE@rice.edu> References: <20130720112218.GD13628@caravan.chchile.org> <115EDC04-4B95-4FB5-9092-515188D8ADA7@rice.edu> <20130721215038.GE13628@caravan.chchile.org> <EDF1EFE1-E9A9-44CF-8007-A642971572BE@rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Wiadomo=B6=E6 napisana przez Alan Cox <alc@rice.edu> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F4779BEB-6F48-4A98-867C-DB40320F7865>