> 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
