Date: Tue, 13 Jul 1999 02:30:12 -0500 From: Alan Cox <alc@cs.rice.edu> To: Dmitrij Tejblum <tejblum@arc.hq.cti.ru> Cc: Jason Evans <jasone@canonware.com>, 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: <19990713023012.K6401@cs.rice.edu> In-Reply-To: <199907121853.WAA27876@arc.hq.cti.ru>; from Dmitrij Tejblum on Mon, Jul 12, 1999 at 10:53:49PM %2B0400 References: <Pine.BSF.4.05.9907121109280.19167-100000@sturm.canonware.com> <199907121853.WAA27876@arc.hq.cti.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 12, 1999 at 10:53:49PM +0400, Dmitrij Tejblum wrote: > > I don't see how MAP_ANON is better than MAP_STACK. > It consumes fewer resources. Each time you grow the stack, it adds another vm_map_entry to the vm_map and (eventually) allocates another vm_object. Using MAP_ANON, there is at most one vm_object and one vm_map_entry (until an mprotect chops it up). > ... > > Anyway, what are the advantages of mmap over malloc? Especially if you change > MAP_STACK to MAP_ANON? > None really. But, the real point (as I've explained on the -committers list) is that there's no reason to use MAP_STACK in a FreeBSD-native program. Alan P.S. As an aside, just once, everyone should look at the /proc/"pid"/map of a running cvsup. Each line you see is a vm_map_entry. (What you see is a result of Modula-3's garbage collector.) Roughly speaking, on a page fault, if we're not faulting on the same range of addresses as the last page fault, a linear cost search is performed to find the correct entry. 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?19990713023012.K6401>