linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Eric B Munson <ebmunson@us.ibm.com>
To: Dave Hansen <dave@linux.vnet.ibm.com>
Cc: linux-mm@kvack.org, nacc <nacc@linux.vnet.ibm.com>,
	mel@csn.ul.ie, andyw <andyw@linux.vnet.ibm.com>
Subject: Re: [RFC][PATCH 2/2] Add huge page backed stack support
Date: Fri, 02 May 2008 14:44:45 -0700	[thread overview]
Message-ID: <1209764685.8581.13.camel@grover.beaverton.ibm.com> (raw)
In-Reply-To: <1209748542.7763.39.camel@nimitz.home.sr71.net>

[-- Attachment #1: Type: text/plain, Size: 1759 bytes --]

On Fri, 2008-05-02 at 10:15 -0700, Dave Hansen wrote:
> On Thu, 2008-05-01 at 18:51 -0700, Eric B Munson wrote
> > The GROWSUP and GROWSDOWN VM flags are turned off because a hugetlb backed
> > vma is not resizable, so it will be appropriately sized when created.  When
> > a process exceeds stack size it recieves a segfault exactly as it would if it
> > exceeded the ulimit.
> 
> This one is *really* subtle.  The segfault might behave like breaking a
> ulimit.  But, unlike a ulimit, you can't really work around this
> particular limitation very easily.

I must have not articulated the way things are working well enough.  The
vma that is created for the process stack is sized to hold ulimit /
HPAGE_SIZE huge pages if ulimit is not unlimited.  If ulimit is
unlimited it holds 256MB / HPAGE_SIZE pages.  256MB was picked because
it is a decent comprimise between large stacks and leaving some of a 32
bit address space available.  The segfault is as easily solved as
adjusting the ulimit for stack size.  If ulimit is raised the stack vma
will be bigger to match.  So it does behave exactly as base page stacks
would when you exceed the ulimit for stack size.

> 
> This will really suck for anyone that tries to use 64k huge pages on
> powerpc, right?

Can you expand on this some, I am not sure what you are getting at.

> 
> Are you actually looking to get this included, or are you just trying to
> play with this?  It is useful as a toy as-is, but I think you should
> look at fixing stack growing before it gets merged anywhere.

I am looking for comments and eventually to be merged.  What would take
to get something along this idea merged?  Is anyone completely opposed,
and if so why?

> 
> -- Dave
> 


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

      reply	other threads:[~2008-05-02 21:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-02  1:51 Eric B Munson
2008-05-02 17:11 ` Dave Hansen
2008-05-02 17:20   ` Dave Hansen
2008-05-02 21:52     ` Eric B Munson
2008-05-02 17:15 ` Dave Hansen
2008-05-02 21:44   ` Eric B Munson [this message]

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=1209764685.8581.13.camel@grover.beaverton.ibm.com \
    --to=ebmunson@us.ibm.com \
    --cc=andyw@linux.vnet.ibm.com \
    --cc=dave@linux.vnet.ibm.com \
    --cc=linux-mm@kvack.org \
    --cc=mel@csn.ul.ie \
    --cc=nacc@linux.vnet.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