public inbox for libc-hacker@sourceware.org
 help / color / mirror / Atom feed
From: Mark Brown <bmark@us.ibm.com>
To: Steve Munroe <sjmunroe@us.ibm.com>
Cc: libc-hacker@sources.redhat.com, Roland McGrath <roland@redhat.com>
Subject: Re: Dealing with multiple page sizes in NPTL
Date: Thu, 03 Nov 2005 15:33:00 -0000	[thread overview]
Message-ID: <OF34F02D1E.E7B6D821-ON062570AE.0053B4E1-062570AE.00557F7C@us.ibm.com> (raw)
In-Reply-To: <OFAD0524DE.CC802B1D-ON8625709D.0074746E-8625709D.0079AEF8@us.ibm.com>

Steve, Roland,


Steve Munroe wrote:
> Roland McGrath <roland@redhat.com> wrote on 10/16/2005 07:54:15 AM:
> 
> > 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).

The Standard is unclear on whether PTHREAD_STACK_MIN includes the 
guard page, or if the guard page is considered to be allocated in addition 
to
the stack size requested by the application. The Joint Working Group is
happy with this being unspecified (meaning it can be implemented either
way and be conforming); I brought the question up, Ulrich replied with how
glibc implements it, and there are no objections at present even from
those who implement it the other way (as an addition to requested size).


-------------------

bmark@us.ibm.com

  reply	other threads:[~2005-11-03 15:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-21 14:06 Steve Munroe
2005-10-16 12:54 ` Roland McGrath
2005-10-17 22:09   ` Steve Munroe
2005-11-03 15:33     ` Mark Brown [this message]
2005-10-27 18:29   ` Steve Munroe
2005-11-17 14:54   ` Steve Munroe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=OF34F02D1E.E7B6D821-ON062570AE.0053B4E1-062570AE.00557F7C@us.ibm.com \
    --to=bmark@us.ibm.com \
    --cc=libc-hacker@sources.redhat.com \
    --cc=roland@redhat.com \
    --cc=sjmunroe@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).