Increase pthread's default stack size
authorBarret Rhoden <brho@cs.berkeley.edu>
Wed, 29 Jul 2015 16:05:59 +0000 (12:05 -0400)
committerBarret Rhoden <brho@cs.berkeley.edu>
Mon, 3 Aug 2015 17:52:58 +0000 (13:52 -0400)
commit7148a229e8f7747ad66aa5d577e650565b86e8a6
treed7aefe72c209ef2c614a7af38f5df753a0af7c8b
parent0fc3e5fe87020f089942fd669cf7c6cf6714b878
Increase pthread's default stack size

We had a bug where cs would occasionally fail service lookups.  It
appeared that cs's threads were running on the small stack and probably
clobbering some memory, leading to the failure.

Increasing the stack size is not ideal - ideally, we'd have applications
and schedulers that were smarter.  Otherwise, we'll be back again the
next time we have some weird corruption due to various library calls.

For this commit, I turned up the size to 4 MB.  Since we don't want to
actually allocate that much per thread, we no longer MAP_POPULATE it.
But we do fault in the first (top) page of the stack.  This prevents us
from taking the page fault later on, when we could be measuring things.

Again, smarter schedulers and applications can do something more
intelligent.

Another option is to implement guard pages in pthreads.  I'm a little
reluctant to do that, since it means the number of VMRs in the kernel is
O(nr_pthreads).  Every stack would take two VMRs, one for the stack and
one for the guard.

Perhaps we can make guard pages an option, turned on by default for
'legacy' apps and turned off for high-perf apps, similar to how we deal
with TLS.
user/pthread/pthread.c
user/pthread/pthread.h