Date: Wed, 16 Feb 2000 16:16:12 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Jason Evans <jasone@canonware.com>, current@FreeBSD.ORG Subject: Re: Heads up, vm.max_proc_mmap sysctl added Message-ID: <20000216161612.G3509@fw.wintelcom.net> In-Reply-To: <200002162333.PAA54729@apollo.backplane.com>; from dillon@apollo.backplane.com on Wed, Feb 16, 2000 at 03:33:58PM -0800 References: <200002162118.NAA54097@apollo.backplane.com> <20000216141339.C18774@sturm.canonware.com> <20000216141622.E18774@sturm.canonware.com> <200002162333.PAA54729@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Matthew Dillon <dillon@apollo.backplane.com> [000216 16:05] wrote: > > It is possible to fix the problem. We can add a new mmap() flag which > we call MAP_GUARDED which would basically be an anonymous mmap() which > implements a special case in vm_fault. This pager is designed to always > return a failure for the first and last page. The size of the mmap() > determines where the guard pages are and would be stored as part of > the vm_map_entry (only for the MAP_GUARDED case). > > Adjacent vm_map_entry structures with the same guard size would be > coalesced. > > Thus any threaded program will still only require a single vm_map_entry > field yet still be completely flexible in regards to the guard pages. > > Is anyone interested in me doing this for the 4.0 release? It would > help both our current threads model and the linux threads model a lot. > I can do it in a day and it should be trivial to test, the modifications > are actually quite minor. I'd love to see it happen for 4.0. Toss some diffs up and we'll see if Jordan gives it an ok. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000216161612.G3509>