Re: Dealing with multiple page sizes in NPTL

[Roland McGrath <roland at redhat dot com>]

There are a few issues here.  

Certainly it should choose a default stack size that it will accept.  I've
committed a change to nptl/init.c so that it applies the same minimum (based
on the page size) that the EINVAL check in allocatestack.c will demand.

It's not clear to me why the allocatestack.c check is as it is:

      if (__builtin_expect (size < (guardsize + __static_tls_size
				    + MINIMAL_REST_STACK + pagesize_m1 + 1),

Requiring the guard size plus the minimum usable size plus another page
seems odd.  Off hand, it makes more sense to require the guard size plus
just the minimum usable size, or that rounded up to a page.  But I won't
presume to change this calculation before Ulrich comments on it.  Whatever
the calculation is, the defaulting code in init.c should be updated to match.

A different question is PTHREAD_STACK_MIN.  When an application allocates
its own thread stack, then 16384 may be perfectly adequate regardless of
the page size.  One can make the case that an application writer might want
to minimize memory consumption at the expense of foregoing guard pages.  A
clever application writer might even do his own allocation with guard pages
below but use the rest of the page above the stack for other purposes, when
the page size is much larger than the actual stack requirements.

However, the standard would seem to indicate that an application can use
pthread_attr_setstacksize without pthread_attr_setstackaddr (and rather
than pthread_attr_setstack), passing PTHREAD_STACK_MIN, and expect to
create a thread with a guard page.  For that to work, PTHREAD_STACK_MIN has
to be at least a page over the minimum usable stack (for the guard page).
The standard explicitly mentions that the effective guardsize may be
page-rounded.  I don't think the standard clearly says whether the
guardsize is included in the stacksize, but that's what we do.  That being
the case, PTHREAD_STACK_MIN not being more than a page just makes no sense.
There is an argument to be made that when pthread_attr_setstacksize
succeeds without complaint (because the PTHREAD_STACK_MIN minimum was met),
then pthread_create should not then fail because that size is too small.
The only way to oblige that is to round up the requested size when
allocating, to big enough for the guard page and the minimum usable stack.
But then that runs afoul of the specification that it's "the size of the
thread stack", meaning that the application might expect it to be exact
(with reliable overflow behavior).  

It may well be desireable to change PTHREAD_STACK_MIN.  Some other
platforms have larger sizes (ia64 has 192k, enough for 64k pages to work).
Or, POSIX allows us to omit the compile-time definition entirely, and
oblige applications to use sysconf--then no particular value would be
compiled into applications.  But, doing either of those is an ABI change.
Programs that used PTHREAD_STACK_MIN according to the proper API were
compiled into existing binaries using the 16384 value; those have a right
to keep working.  That's why we have that compatibility code in
pthread_attr_setstacksize and pthread_attr_stack, for the platforms that
got a new ABI in the GLIBC_2.3.3 version set changing the PTHREAD_STACK_MIN
value exposed to applications.

If you want to change PTHREAD_STACK_MIN for powerpc, then you have to add
similar compatibility code for the old ABI that will have to be obsoleted
by a GLIBC_2.4 version of pthread_attr_setstack{,size}.  I would also be
open to removing PTHREAD_STACK_MIN as a compile-time invariant.  That both
requires some more futzing in libc, and has potential fallout in terms of
source compatibility with not-quite-compliant applications that assume
there is a macro giving a constant value.


Thanks,
Roland