From owner-freebsd-current Tue Jul 13 3:28:32 1999 Delivered-To: freebsd-current@freebsd.org Received: from not.demophon.com (ns.demophon.com [193.65.70.13]) by hub.freebsd.org (Postfix) with ESMTP id A949614D70 for ; Tue, 13 Jul 1999 03:28:27 -0700 (PDT) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id NAA10088; Tue, 13 Jul 1999 13:23:22 +0300 (EEST) (envelope-from will) To: Alan Cox Cc: current@freebsd.org Subject: Re: Thread stack allocation (was Re: cvs commit: src/lib/libc_r Makefile src/lib/libc_r/uthread pthread_private.h uthread_create.c uthread_gc.c uthread_init.c) References: <199907121853.WAA27876@arc.hq.cti.ru> <19990713023012.K6401@cs.rice.edu.newsgate.clinet.fi> <86673p7y28.fsf@not.demophon.com> <19990713040156.N6401@cs.rice.edu.newsgate.clinet.fi> From: Ville-Pertti Keinonen Date: 13 Jul 1999 13:23:21 +0300 In-Reply-To: Alan Cox's message of "13 Jul 1999 12:04:49 +0300" Message-ID: <863dys97c6.fsf@not.demophon.com> Lines: 30 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alan Cox writes: > Almost all of these vm_map_entry's started out as a single entry that got > fragmented as mprotects were performed by the garbage collector. > Instead of maintaining the page protections as part of the vm_map_entry, > you could separate them into a smaller, specialized data structure that is > attached to the original vm_map_entry. (SVR4, Solaris and Digital > Unix use some variation of an array with an entry per page.) > This way you address the problem by limiting the growth of the vm_map's > list of vm_map_entry's. That might be useful, and in FreeBSD it wouldn't be too hard to avoid breaking APIs (like in in Digital UNIX, where vm_region no longer returns accurate info). But arrays may be costly, VM regions can be large (look at e.g. anonymous mapping arrays in NetBSD's UVM), and you need to keep track of the protection of both mapped and unmapped pages. And this is a special case involving a small class of programs that use the virtual memory system for internal memory management. I'm pretty sure that moderately large numbers of distinct mmapped objects are more common. > In the end, you may want to combine both approaches. I can't say > for sure. I suspect that trees are going to be necessary at some point. Of course it isn't up to me, but common programs may start to require something to be done. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message