From owner-freebsd-current Mon Jul 12 11:54:56 1999 Delivered-To: freebsd-current@freebsd.org Received: from arc.hq.cti.ru (arc.hq.cti.ru [195.34.40.3]) by hub.freebsd.org (Postfix) with ESMTP id 2BDB014DCC; Mon, 12 Jul 1999 11:54:51 -0700 (PDT) (envelope-from tejblum@arc.hq.cti.ru) Received: from arc.hq.cti.ru (localhost [127.0.0.1]) by arc.hq.cti.ru (8.9.3/8.9.3) with ESMTP id WAA27876; Mon, 12 Jul 1999 22:53:49 +0400 (MSD) (envelope-from tejblum@arc.hq.cti.ru) Message-Id: <199907121853.WAA27876@arc.hq.cti.ru> X-Mailer: exmh version 2.0zeta 7/24/97 To: Jason Evans 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) In-reply-to: Your message of "Mon, 12 Jul 1999 11:28:58 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Jul 1999 22:53:49 +0400 From: Dmitrij Tejblum Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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