Date: Mon, 12 Jul 1999 22:53:49 +0400 From: Dmitrij Tejblum <tejblum@arc.hq.cti.ru> To: Jason Evans <jasone@canonware.com> Cc: current@FreeBSD.org, alc@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: <199907121853.WAA27876@arc.hq.cti.ru> In-Reply-To: Your message of "Mon, 12 Jul 1999 11:28:58 PDT." <Pine.BSF.4.05.9907121109280.19167-100000@sturm.canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Mon, 12 Jul 1999, Dmitrij Tejblum wrote: > > Alan Cox wrote: > > > When you create a stack or grow an existing stack, the minimum chunk size > > > is 128K. > > > > This make use of "growable" stacks in libc_r particulary useful, given that > > libc_r make "growable" only 64K stacks. > > That is a problem, to be sure. In order to make effective use of growable > stacks, each stack really needs to be at least 256KB. However, Alan also > pointed out that growable stacks are a bit of a non-feature, since the VM > is lazy about backing mapped regions. In light of this, I'm leaning > toward using MAP_ANON instead of MAP_STACK. I don't see how MAP_ANON is better than MAP_STACK. > > These changes create other troubles. For example, they limit the size of the > > initial thread to 1M, and this is too little and not tunable. > > Making the initial stack size tunable at runtime would require a > non-standard interface. How big is big enough? I picked 1MB rather > randomly; increasing the value is quite easy. One possible solution would > be to pay at least some heed to the value of getrlimit(RLIMIT_STACK, ..). Well, why you map stacks on fixed address, and in the process stack? I think, you could map it at random address. (And mprotect the red zone). > Another problem with the changes I made was also pointed out by Alan. > Each stack is a separate region, and with the red zones, there end up > being two regions for every stack. This apparently has a direct impact on > page table lookups. Somehow, the stack allocation code needs to be more > economical in this regard, but I haven't thought of a slick method yet. Anyway, what are the advantages of mmap over malloc? Especially if you change MAP_STACK to MAP_ANON? Dima 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?199907121853.WAA27876>