From: Tony Luck <tony.luck@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: James Bottomley <James.Bottomley@hansenpartnership.com>,
Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>,
Fenghua Yu <fenghua.yu@intel.com>,
Hugh Dickins <hughd@google.com>,
linux-kernel@vger.kernel.org, linux-parisc@vger.kernel.org,
Michel Lespinasse <walken@google.com>,
Oleg Nesterov <oleg@redhat.com>,
linux-ia64@vger.kernel.org
Subject: Re: [PATCH] Don't mlock guardpage if the stack is growing up
Date: Mon, 09 May 2011 22:53:33 +0000 [thread overview]
Message-ID: <BANLkTi=DCKmN_BafFckKHOMfjWpVLQPDFA@mail.gmail.com> (raw)
In-Reply-To: <BANLkTim7ATRyJ2NvoCj4Sv=7CLizKMd_WA@mail.gmail.com>
On Mon, May 9, 2011 at 3:31 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> With current kernels, I think the stack expands by one page during the
> mlockall (for STACK_GROWSUP), with the patch it shouldn't.
Tried this on ia64 (with a mod because the upward growing stack isn't
blessed with
the [stack] annotation, only the downward growing stack gets that honour).
ia64 builds, boots, and processes can still grow stacks (both of them). The
patched kernel doesn't change the size of the upwardly growing stack across
the mlockall().
-Tony
P.S. while we could start both stacks on the same page and have the grow
away from the start point, ia64 actually starts them out a fair distance apart
and lets them run into each other (if you have enough memory to let them
grow that far, and if ulimit -s doesn't stop them earlier)
next prev parent reply other threads:[~2011-05-09 22:53 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <alpine.DEB.2.00.1105082045250.15552@artax.karlin.mff.cuni.cz>
[not found] ` <alpine.LSU.2.00.1105081303540.16151@sister.anvils>
[not found] ` <alpine.DEB.2.00.1105091307570.32299@artax.karlin.mff.cuni.cz>
[not found] ` <BANLkTinCUQSjjif3op3H_9HDm5Eu-o+Luw@mail.gmail.com>
2011-05-09 22:07 ` [PATCH] Don't mlock guardpage if the stack is growing up Linus Torvalds
2011-05-09 22:19 ` James Bottomley
2011-05-09 22:31 ` Linus Torvalds
2011-05-09 22:53 ` Tony Luck [this message]
2011-05-09 22:58 ` Linus Torvalds
2011-05-09 23:08 ` Tony Luck
2011-05-09 23:17 ` Linus Torvalds
2011-05-09 23:25 ` Linus Torvalds
2011-05-10 4:12 ` James Bottomley
2011-05-09 22:26 ` Mikulas Patocka
2011-05-15 22:18 ` Mikulas Patocka
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='BANLkTi=DCKmN_BafFckKHOMfjWpVLQPDFA@mail.gmail.com' \
--to=tony.luck@gmail.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=fenghua.yu@intel.com \
--cc=hughd@google.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=mikulas@artax.karlin.mff.cuni.cz \
--cc=oleg@redhat.com \
--cc=torvalds@linux-foundation.org \
--cc=walken@google.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