Date: 13 Jul 1999 13:23:21 +0300 From: Ville-Pertti Keinonen <will@iki.fi> To: Alan Cox <alc@cs.rice.edu> 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) Message-ID: <863dys97c6.fsf@not.demophon.com> In-Reply-To: Alan Cox's message of "13 Jul 1999 12:04:49 %2B0300" References: <Pine.BSF.4.05.9907121109280.19167-100000@sturm.canonware.com> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
Alan Cox <alc@cs.rice.edu> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?863dys97c6.fsf>