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
next prev parent 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).